Sun stelt Rock-servers een jaar uit

Sun heeft zijn Rock-processor een jaar uitgesteld. De UltraSparc-processor met 16 cores zou nu pas in de tweede helft van 2009 verschijnen, in plaats van zoals eerder beloofd in de tweede helft van 2008.

Sun-technicus John Fowler geeft de complexiteit van de nieuwe processor de schuld voor het uitstel. Tegenover de Automatisering Gids verklaart hij dat zijn bedrijf zwaar heeft moeten investeren om ervoor te zorgen dat zowel de hardware als de software foutloos werken.

Het bedrijf meldde op 11 april al dat het de eerste exemplaren van de chip in huis had, maar daarna duurde het nog tot 2 mei voor men er in slaagde om het binnenshuis ontwikkelde Solaris er op te laten starten. Ter referentie lukte het Intel binnen een paar uur om Windows te booten op de eerste Penryns.

Het uitstel lijkt erop te wijzen dat het testen sindsdien niet veel soepeler is gaan lopen, wat gegeven de complexiteit van het ontwerp misschien ook niet verwonderlijk is. Het gerucht wil dat Rock een soort hybride is tussen een quadcore en een 16-core ontwerp, waarin groepen van vier subcores met ieder twee threads elkaars caches en rekenkracht kunnen benutten.

Reacties (14)

[killercow]

Ter referentie lukte het Intel binnen een paar uur om Windows te booten op de eerste Penryns

Serieus, wat is dit nou voor vergelijking,

De niagara en Rock cpu's zijn Zo veel anders dan de normale sparcs dat de vergelijking tussen met een serie X86 cpu's compleet niet op gaat.

Ik gok dat IBM / Sony ook wel enkele maanden bezig zijn geweest met het bouwen van een OS / Kernel voor de cell cpu, zijn zij dan ook langzaam?

[Wouter Tinus]

De niagara en Rock cpu's zijn Zo veel anders dan de normale sparcs dat de vergelijking tussen met een serie X86 cpu's compleet niet op gaat.

Ze gebruiken dezelfde instructieset, dus aan de software zou niets aangepast moeten worden om te kunnen draaien. Als dat wel het geval is betekent dat al dat er een probleem is. Dat het vervolgens zelfs met volledige toegang tot de OS-kernel een maand duurt voor ze dat kunnen traceren en omzeilen geeft aan dat het een redelijk serieus probleem is.

Ik gok dat IBM / Sony ook wel enkele maanden bezig zijn geweest met het bouwen van een OS / Kernel voor de cell cpu, zijn zij dan ook langzaam?

Het zou mij verbazen als Linux niet binnen notime op de Cell draaide. De standaard PPC-core die dat gedeelte verzorgt is voor IBM kinderspel.

[burne]

Het geeft voor mij vooral aan dat je de schaal en complexiteit van het probleem gemist hebt. Om je een concreet voorbeeld te geven: in OS/360, wat dit jaar 42 jaar oud wordt, zitten nog altijd een duizendtal bugs. Denk niet dat kernels debuggen makkelijk is.

Linux draait sinds februari 2006 op de Cell-enabled QS-20 blade van IBM. Het probleem is dat draaien op de PPC-core geen kunst is, maar iets doen met die acht cell-processoren wel. Geen van de bestaande applicaties kan daar iets mee, en apps die specifiek voor gebruik op de QS-20 geschreven worden zullen niet op andere hardware draaien. Sun heeft de lat iets hoger liggen. Een app geschreven voor Rock zou zonder aanpassingen ook op een 'normale' UltraSparc of een Niagara moeten draaien.

[Wouter Tinus]

Het geeft voor mij vooral aan dat je de schaal en complexiteit van het probleem gemist hebt.

De complexiteit heeft er weinig mee te maken, er is gewoon een schema en daarin worden bepaalde mijlpalen gehaald of niet. Als Sun er geen vertrouwen in had gekregen (a.d.h.v. simulaties en emulators) dat ze klaar waren om de fysieke hardware te gaan testen, dan hadden ze de eerste samples niet laten produceren (dat geintje kost namelijk wel een week of zes-zeven en een paar miljoen dollar). Als dat dan vervolgens maar heel moeizaam lukt betekent dat duidelijk dat men onverwacht tegen lastige bugs aan is gelopen, dus dan schuift de rest van de planning ook door.

De bootgrap heeft dus drie weken gekost, maar kennelijk heeft het zich nu al zo ver opgestapeld dat een uitstel van 6+ maanden nodig is.

Sun heeft de lat iets hoger liggen. Een app geschreven voor Rock zou zonder aanpassingen ook op een 'normale' UltraSparc of een Niagara moeten draaien.

Dit heeft er ook niets mee te maken, komt allemaal pas veel later in het validatie/ontwikkelingsproces. Het enige wat ze nodig hadden om Solaris te booten is een machine met één processor, met daarop één core en één actieve thread. En die moet inderdaad gewoon compatible zijn met de standaard SPARC-instructieset, dus software/kernel aanpassingen zouden nergens voor nodig moeten zijn. Als dat nog niet eens lukt dan is er gewoon iets misgegaan, en dan ben je dus nog niet eens begonnen om het multithreading, multicore en multiprocessorgedeelte te testen, laat staan dat je al bezig bent om de prestaties te optimaliseren.

[Reactie gewijzigd door Wouter Tinus op 30 juli 2024 23:10]

[niqck]

Naast de instructieset bestaat er ook nog zoiets als de architectuur van het systeem. De instructie-set van bv. de Niagara T1 is idd SPARC maar de architectuur is sun4v. De US, US-II, US-III en US-IV zijn sun4u architecturen. Daarvoor had je dan nog eens sun4d , sun4m, sun4c, sun4-e, sun4u-1... Al deze cpu's maken gebruik van de SPARC-instructie-set maar zijn compleet andere architecturen met de daarbijhorende architectuur-specifieke libraries en kernel.
De Rock zal opnieuw een nieuwe architectuur hebben.

De PPC en de Power-chips van IBM gebruiken ook hetzelfde instructieset maar ik betwijfel dat jij even snel een MacOS op een Power-series van IBM zal booten.

[lammert]

Het is wel een beetje simplistisch gedacht dat als een CPU dezelfde instructieset gebruikt dat een daarvoor gecompileerd OS dan ook maar meteen goed moet werken. Er zijn meer variabelen in het spel dan alleen een instructieset. Bijvoorbeeld de nieuwe hardware die samenhangt met het nieuwe socket, daar is een geheel nieuw moederbord voor ontworpen.

Daarnaast duurde het "slechts" 3 weken en niet een maand voordat ze Solaris aan de praat hadden op de Rock. (Is misschien mierenneukerij, maar als eindredacteur mag je best op de "feitjes" letten die je post).

[Wouter Tinus]

Het is wel een beetje simplistisch gedacht dat als een CPU dezelfde instructieset gebruikt dat een daarvoor gecompileerd OS dan ook maar meteen goed moet werken.

Bij Intel hebben ze er duidelijk geen problemen mee, booten binnen een dag is daar eerder de regel dan de uitzondering. De software en systeemborden worden al lang voor de fysieke chip terugkomt uit de fabriek getest door middel van emulators. Dat zullen ze bij Sun ongetwijfeld ook gedaan hebben, maar kennelijk gedroeg de fysieke chip zich toch een beetje lastiger dan de simulatie.

[Reactie gewijzigd door Wouter Tinus op 30 juli 2024 23:10]

[flowerp]

Bij Intel hebben ze er duidelijk geen problemen mee, booten binnen een dag is daar eerder de regel dan de uitzondering.

Het hangt natuurlijk ook sterk van de context af. In welke fase van ontwikkeling zit het product wanneer je het probeert te booten? Die rock CPU van 11 April, was dat de 100% final versie? Dan zou het wel raar zijn dat Solaris er niet op boot, aangezien je er van uit mag gaan dat tijdens de ontwikkeling van de CPU je meerdere keren er iets op probeert de draaien. Net zoals je niet software ontwikkeld door in 1 keer 50.000 regels te schrijven en het als die 50.000 regels geschreven zijn het pas voor de allereerste keer gaat compilen en daadwerkelijk draaien.

Aangezien het dus nog een jaar duurt, neem ik aan dat er nog gesleuteld wordt aan die Rock, of is dat niet het geval?

De intel vergelijking is natuurlijk ook moeilijk. Wellicht dat men standalone bootloaders en later ook Windows zelf er al diverse keren op geboot hadden tijdens de ontwikkeling (op de diverse gesimuleerde versies and prototypes). Dat men dan uberhaupt nog een paar uur nodig heeft om Windows op de eerste final te laten booten is al vreemd. Wat doet men dan in die paar uur? De microcode van de CPU aanpassen? Patches voor de Windows kernel proberen te schrijven?

Voordat je een CPU bakt in een final versie die hoofdzakelijk bedoeld is om Windows te gaan draaien, heb je toch al 10.000'en regressie testen en simulaties in het laboratorium gedraaid? Als dan de final van de band rolt en je hem in je test Dell PC stopt, dan verwacht ik eigenlijk eerder dat Windows er gewoon na 1 seconden op boot.

Vergelijk het nogmaals met software development. Als je maanden aan b.v. een web applicatie werkt heb je die al velen malen getest voordat je die in productie gooit. Als je dan nog een paar uur nodig hebt om hem daarna echt werkend te krijgen (en je site dus een paar uur plat ligt) dan was het dus niet echt een final versie die je in productie ging zitten.

[humbug]

Dat men dan uberhaupt nog een paar uur nodig heeft om Windows op de eerste final te laten booten is al vreemd. Wat doet men dan in die paar uur? De microcode van de CPU aanpassen? Patches voor de Windows kernel proberen te schrijven?

Je kan ervan uit gaan dat er een aardig handboek bij Intel ligt waarin een compleet stappenplan ligt voor dit traject. En dat is niet. Ram je chip in een moederboard, koppel het aan een harddisk met windows en boot. Meer "controleer jumper A. Zet handtekening. Controleer Jumper B. Zet handtekening." Enz enz. Dat kost dus wel wat tijd.

[Cobalt]

ik denk dat jij je eens mag gaan verdiepen in hoe cpu's werken. 16 cores worden echt wel goed benut, zeker in servers. Het schrijven van een multi threaded programma is zeer eenvoudig.
Of één programma 16 cores gebruikt is maar de vraag. Dat ligt er gewoon aan of er zoveel taken parallel gedaan kunnen worden. Bij een webserver zou dat makkelijk kunnen.
Eén programma hoeft niet alle cores te benutten, er zijn vaak meerdere programma's actief en je OS is ook een programma.

[donotwant]

om maar te zwijgen over het nut van virtualisatie

[Verwijderd]

zijn zo'n processoren niet deels bedoelt om in supercomputers te dienen?

[daft_dutch]

Weer iemand die de desktop met een server vergelijkt. (lees spelletjes)
Als men 1 server pakt voor bijvoorbeeld een apache/php/mysql servertje. (suf voorbeeld maar ja)
kan je voor 1 webverzoek al twee theads draaien. 1 voor apache/php en 1 voor de sql select. doe dat eens keer X (de aantal verzoeken per minuut) en een beetje rekenaar weet dat je Heel graag veel theads tegelijk wilt draaien.
Daardoor wordt een website uit elkaar getrokken in een zooi servers. Omdat er te veel theads zijn voor de servers die nu bestaan.

[Reactie gewijzigd door daft_dutch op 30 juli 2024 23:10]