'Geïntegreerde geheugencontroller Intel alleen voor servers'

Intel heeft geen plannen om een geheugencontroller te integreren in het gros van zijn chips voor desktops en laptops, aldus The Inquirer. Een Extreme Edition met geheugencontroller wordt nog wel overwogen, maar de enige zekerheid ligt bij Xeon en Itanium.

Waarom men er voor desktops nog steeds niet aan wil beginnen terwijl er voor servers een aantal veelbelovende plannen liggen blijft nog onduidelijk. Onder andere de flexibiliteit van een externe geheugencontroller is een vaak genoemd argument, want van socketwissels wordt niemand heel vrolijk. Voor de prestaties is het in een desktop ook niet zo belangrijk als voor een server, waardoor men wellicht liever voor lagere productiekosten kiest. Uiteraard komen die er aan de kant van de chipset alsnog bij, maar daar worden dan ook extra inkomsten door gegenereerd. Dit hoeft overigens niet te betekenen dat de fsb in zijn huidige vorm blijft bestaan: een voor de hand liggende optie is dat men overstapt op een seriële verbinding met de chipset, zoals toekomstige Xeons en Itaniums met elkaar zullen communiceren.

Als de geruchten kloppen betekent het dat het bedrijf drie verschillende technische wegen inslaat: de Itanium en Xeon MP krijgen een waarschijnlijk grotendeels identiek systeem dat bekend staat als de Coherent Scalable Interconnect, of kortweg CSI. Iedere processor kan hiermee direct met vier andere processors praten, net als Opterons doen via HyperTransport. Intels versie gebruikt echter een geavanceerder protocol gebaseerd op directories, een soort telefoonboek waar in staat waar de laatste versie van ieder stuk data gevonden kan worden. Hierdoor wordt de hoeveelheid overbodig verkeer tot een minimum beperkt, in contrast met het systeem van AMD waarbij steeds álle processors moeten worden aangesproken. De Itanium 'Tukwila' (2008) en Xeon MP 'Beckton' (2009) krijgen dit systeem en maken gebruik van een geïntegreerde fbdimm-controller met vier kanalen, plus een extra redundant kanaal. Zelfs uitgaande van de huidige 667MHz-modules zou een CSI-machine met vier sockets al 85GB/s aan bandbreedte tot zijn beschikking hebben, een grote sprong ten opzichte van het huidige Truland-platform (12,8GB/s) en later dit jaar verwachte Caneland-platform (34,1GB/s). Ondersteuning voor snellere geheugensmaken - wat wel waarschijnlijk lijkt - zou de sprong nog groter maken.

De gewone Xeon voor servers met één of twee sockets krijgt niet de volledige versie van CSI, maar toch een geïntegreerde geheugencontroller. Intel stapt voor dit segment weer af van het vorig jaar geïntroduceerde fbdimm-geheugen, dat vaak wordt bekritiseerd vanwege de kosten, latency en het hogere stroomverbruik ten opzichte van normale ddr2-repen. In plaats daarvan zou de voor 2008 geplande 'Gainstown' een driekanaals ddr3-controller met ondersteuning voor 1333MHz-repen krijgen. Dit betekent dat er voor twee sockets tot 64GB/s bandbreedte beschikbaar komt, een verdrievoudiging ten opzichte van de huidige situatie. AMD heeft vooralsnog geen concrete plannen aangekondigd om meer bandbreedte per socket te gaan leveren, maar heeft wel altijd gezegd nieuwe technieken zoals fbdimm te zullen gebruiken zodra ze nodig zijn. Het risico om ver achterop te raken zou voldoende motivatie moeten zijn, dus ongetwijfeld zullen ze ook niet stilzitten.

	Bandbreedte per socket
	Xeon DP (Gainstown - 2008)	32,0
	Xeon MP (Beckton - 2009)	21,3+
	Xeon DP (Harpertown - 2007)	12,8
	Xeon DP (Woodcrest/Clovertown)	10,7
	Opteron (Socket F)	10,7
	Xeon MP (Tigerton - 2007)	8,5
	Xeon MP (Tulsa)	3,2

Alle cijfers in gigabyte per seconde

Reacties (29)

[cheijkoop652]

Wel mooi om te zien dat Intel goed om zich heen kijkt. De x-Archtecture servers van een groot merk heeft al jaren een snoop filter in haar chipset ingebouwd waardoor de processoren en de bus ontlast worden. Het snoop filter is een directory waarin staat welke processor welk geheugengebied in gebruik heeft.... he dat komt weer bekend voor.

Goede zaak, jammer dat het alleen voor de server chips wordt toegepast.

[Verwijderd]

Zou er dan toch een eind komen aan de FSB?

Volgens mij de enige techniek die het heeft volgehouden sinds het begin van de computers zoals we die nu kennen (eind jaren 80).

Ook de PS/2 poort heeft het erg lang volgehouden, maar begint ook langzaam te verdwijnen (vaak is het enkel nog het toetsenbord, maar ook die wordt steeds vaker via USB aangesloten).

En natuurlijk de oeroude floppy, die tegenwoordig al bijna is uitgestorven, maar dankzij de brakke installatie van Windows 2000 en Windows XP nog altijd aanwezig op het moederbord voor het installeren van de RAID drivers.

Dat zijn volgens mij de enige waarvan de FSB nu dus op het punt staat te verdwijnen (wat ook wel hard nodig is eigenlijk). AMD is al een tijd geleden overgestapt op de HyperTransport bus en ook VIA is overgestapt na het verlopen van de licentie op de techniek.

[Wouter Tinus]

Volgens mij de enige techniek die het heeft volgehouden sinds het begin van de computers zoals we die nu kennen (eind jaren 80).

Niet echt, de huidige bus van Intel is pas een jaar of zes oud (tegelijk met de Pentium 4 geïntroduceerd). Tenzij je alles wat ooit tussen processor en chipset heeft gezeten op een hoop wil vegen, maar dan vallen HyperTransport en CSI er ook onder.

[Verwijderd]

@Wouter Tinus:

Kun je uitleggen wat het verschil is tussen de huidige bus en de bus die daarvoor werd gebruikt? Voor zo ver ik weet werden ze beiden FSB genoemd.

Of anders een linkje?

Is wel interessant om eens te lezen.

[Wouter Tinus]

Klopt, de term FSB is al vrij oud, maar het is dan ook meer een logisch concept - namelijk de verbinding tussen processor en chipset - dan de naam van een techniek of standaard. Zo had je vroeger ook nog een BSB (back side bus) om met het L2-cache te kunnen praten.

De grootste overeenkomst tussen al Intels bussen tot nu toe is dat ze parallel zijn. De basis voor de huidige versie werd gelegd in 1995 met de introductie van de Pentium Pro. Dit was de eerste gebaseerd op GTL+ (Gunning Transceiver Logic) en met de Pentium III werd dat AGTL+ (Advanced Gunning Transceiver Logic). Met de Pentium 4 in 2000 werd de techniek voor het laatst op schop gegooid en werd de bus 'quadpumped', wat betekent dat voor iedere kloktik vier keer data wordt verstuurd.

In de loop der jaren heeft het zich ontwikkeld van 480MB/s voor de Pentium Pro naar binnenkort 12,8GB/s voor de Clovertown. Het 'gezeur' over dat een FSB ouderwets is slaat dus eigenlijk nergens op, dat ding gaat net zo hard met zijn tijd mee als andere computeronderdelen en is zelfs nog sneller dan HyperTransport, dat in zijn huidige vorm 8GB/s per link kan leveren (en maar 4GB/s per richting).

De crux zit hem dus niet in de techniek maar in de context waarin Intel hem gebruikt. Vroeger deelden tot vier processors één bus en dat werd akelig druk. Té druk gewoon eigenlijk. Later zaten er nog maar twee processors per bus, wat al beter was. Nu (vanaf 1066MHz) zit er nog maar één processor per bus, eindelijk de ideale situatie. Een ander probleem is echter nog niet opgelost, en dat is waar deze nieuwspost over gaat: alle processors moeten nog steeds naar één centrale plek toe om bij het geheugen te komen. Hoe meer processors je hebt, hoe groter dat probleem wordt.

AMD heeft dit al in 2003 opgelost door iedere processor zijn eigen geheugencontroller te geven en ze onderling aan elkaar te knopen, in plaats van een chipset te gebruiken als centraal regelpunt. De eisen die de ontwerpers moeten stellen worden ineens heel anders met die filosofie: je hebt ineens niet één maar meerdere verbindingen nodig (3 à 4 per socket om een fatsoenlijk aantal processors te ondersteunen) en bovendien heb je al een hoop extra pinnen voor je geheugencontroller. In plaats van een processor met duizenden pinnen uit te brengen kies je dan liever voor smalle seriële busjes (8-bit of 16-bit) in plaats van parallelle 64/128-bits knoeperts zoals Intel nu heeft.

Het is dus niet HyperTransport dat per se beter is dan een FSB, maar de hele filosofie die tot het ontstaan ervan heeft geleid die netto betere resultaten oplevert. Dit geldt dus voornamelijk voor servers. Voor desktops is het verschil tussen een 64-bit parallelle bus en een 16-bit seriële bus helemaal irrelevant. Het enige belangrijke punt is daar of de geheugencontroller al dan niet op de processor zit, maar dat is strict gezien onafhankelijk van de bustechniek.

[JackBol]

Technisch gezien is er niet veel verschil. Een bus tussen processor het geheugen zijn gewoon een x-aantal koper sporen. FSB/Hypertransport/whatever zijn gewoon de protocollen die tegenwoordig gebruikt worden voor de communicatie tussen processor de geheugen-controller (north-bridge meestal).

Vruugah (lees: 8088, 286 etc.) konden processoren geheugen rechtstreeks uitlezen, en was een protocol helemaal niet nodig. Gooi het adres op de adres-bus en de eerstvolgende clocktick stond je informatie klaar op de databus. Dat waren nog eens tijden!

[CH4OS]

Intel is met de P4 quadpumped geworden...
Waar AMD nog altijd dualpumped is.

Reken maar dat dat effect heeft op je FSB...

[Verwijderd]

@_DH : Toch iemand die het begrijpt.

Je zal inderdaad altijd een FSB of wat dan ook hebben omdat er altijd een interface tussen je geheugen en je CPU zal bestaan.

[_AvA_]

Wat dacht je van het bios, nog altijd 16 bit, en het meest belangrijke op het hele moederbord.

[Mathijs]

IRQ's, ook zoiets dat stokoud is en vervelend omdat het nooit hardwarematig is opgeschaald.

[jiriw]

Ehmmmm ... ik kan me vergissen... maar wat doet APIC dan? Ik heb toch echt wel meer dan 16 interruptlijnen in mijn PC hardware...

[Verwijderd]

En waarom moet het aantal IRQ lijnen dan wel omhoog ?

[Atmosphere]

@jiriw APIC is eigenlijk niet veel anders dan een 2e PIC nadoen waarbij 2 IRQ's tussen beide PIC's gedeelt worden als soort van adressering... hoerdoor heb je 30 IRQ's tot je beschikking...

@Green.Velvet Als nou je wist wat een IRQ was zou je weten waarom het handig is ... nu moet hardware die niet over een IRQ beschikt 'gepolled'(=om de zoveel tijd kijken of er een actie nodig is) worden of van busmastering gebruik maken om 'exclusieve' aandacht van de processor te krijgen. Meer IRQ's betekend minder pollen -> minder latency...

Nadeel is dat deze IRQ's ook veel tijd kunnen wegkapen, omdat de CPU er aandacht aan 'moet' besteden. Ook wordt het lastiger om een prioriteit (des te lager het IRQ.. des te belangerijker de aandacht) aan de verschillende IRQ's mee te geven.

[SKiLLa]

IRQ's, ook zoiets dat stokoud is en vervelend omdat het nooit hardwarematig is opgeschaald.

Dat is de x86 legacy (backward-compatibility), en eigenlijk is de x86 architectuur daardoor na 30 jaar enorm krom & kreupel.

De x86 architectuur voorzag orgineel in slechts 16 hw IRQs, later (APIC) tot hw 256, niet 30. Zie b.v. hierop Wikipedia. Niet dat Wikipedia feilloos is, maar het klopt in dit geval wel

[Atmosphere]

@SKiLLa .. dit is daarna pas... De 486 en pentium boden ruimte voor 32 IRQ's waarvan er bij PIC 1 en PIC 2 in totaal 2 IRQ's gedeeld voor een cascade schakeling

Hmmmz even eigen woorden eten

XT bood ruimte voor 8 IRQ's ... dit hebben ze toen voor AT mbv van bovenstaande constructie omgezet naar 16 (14 effectief)... vanaf de Pentium heeft inderdaad de ZPIC zijn intreden gedaan.

[Verwijderd]

Ik weet heel goed wat een IRQ is, dankuwel. SEI en CLI op 6502 niveau zijn me helemaal niet vreemd en gekke dingen doen met interrupts op de Amiga was ook een leuke tijd.

Dat 'domme' hardware gepolled moet worden klopt, maar dat is geen reden om meer IRQ lijnen te moeten hebben. In theorie is een global IRQ lijn met bijhorende device ID meer dan genoeg om alles netjes af te handelen.

In de praktijk is dit niet zo en deel je de dingen best in categorieen, vooral critical based.

Daarom mijn vraag, waarom zou een systeem 127 of 255 IRQ lijnen moeten hebben ?

Simpel antwoord : niet.

Dat men al lang het een en ander kan verbeteren aan de efficientie... dat is iets heel anders.

Dus het gediscussieer hier over die IRQ lijnen is gewoon een non-issue... zeker ivm. integrated memory controllers.

[Verwijderd]

Die 256 zijn ook geen straight IRQ lijnen, maar worden bereikt via omwegen. Wat inderdaad voor de nodige problemen kan zorgen soms.

[Luxx]

Opvallend is dat de bandbreedte per core nauwelijks groeit, de snelle invoering van dual en quad cores zorgt er voor dat zelfs deze enorme sprongen in bandbreedte zo goed als géen winst per core opleveren. Worden de cores op zich dan nauwelijks sneller, of ontstaat/blijft er tóch een bottleneck bij de bandbreedte?

[RedShift]

De cores zelf kunnen ook maar een beperkte bandbreedte aan, er kunnen maar evenveel gegevens aangevoerd worden als er verwerkt kunnen worden (dit kan wel gedeeltelijk opgelost worden door buffers). Zie het een beetje als de backplane van een switch, die heeft misschien 5 gigabit aan switching capaciteit maar per poortje kan je er toch maar 200 megabits per seconde mee verzetten.

[Wouter Tinus]

De bandbreedte per core heeft inderdaad zijn ups en downs en dat zal wel zo blijven zolang men door blijft gaan met het toevoegen van meer cores. Met de geïntegreerde geheugencontrollers zetten ze nieuwe records neer (ook per core), maar zodra ze overstappen op acht cores per socket zijn die ook ineens niet meer zo indrukwekkend.

De som is volgens mij echter meer waard dan de losse delen, want in de praktijk zal het niet vaak voorkomen dat cores tegelijkertijd volle bak bandbreedte nodig hebben, waardoor degenen die het wél nodig hebben ook meer kunnen krijgen. Ook heb je te maken met gedeelde caches die ervoor zorgen dat twee of vier cores tot op zekere hoogte kunnen samenwerken, in plaats van dat ze strijden om dezelfde bytes als eerste te krijgen.

[Webdoc]

Hmm... die FB-DIMMS beginnen verdacht veel als RDRAM te klinken... 1 (sub) generatie van hardware die er gebruik van maakt, duur, en binnenkort weer vervangen...

[murtoz]

een beetje wel... maar ook weer niet. Voor MP (meer dan 2 sockets) blijft Intel zo te zien wel bij FBDIMM. Aangezien in dat soort systemen vaak aanzienlijk meer geheugen zit dan in een DP, en een van de belangrijkste voordelen van FBDIMM is dat je makkelijk meer geheugen op een channel kan proppen bij dezelfde of hogere snelheid (vergelijk 16GB/channel FBDIMM 533/667; 8GB/channel DDR2 400), is dat eigenlijk ook wel weer logisch.

Nadeel daarbij wel is de hogere latency - maar voor sommige toepassingen (database?) is het totaal beschikbare geheugen weer belangrijker dan een paar tien(/honderd?)-tallen milliseconden winst op geheugen toegang.

Verder lijkt het bovenstaande plaatje aan te geven dat Itanium ook naar FBDIMM toegaat (voor zover ik weet zit dat nu nog op DDR2).

Ik denk dat er dus nog best wel toekomst in FBDIMM zit :-)

[boner]

duurt nooit lang hoor. u nog alleen voor servers, strax voor d hogere prijsklasse en dan voor de mainstream.

Afromen van de markt heet zoiets

[humbug]

Ik denk dat je dat verkeerd ziet. Een single CPU desktop heeft geen communicatie nodig tussen verschillende CPUs. Aangezien het voor de bandbreedte irrelevant is of de geheugen controller nu intern of extern zit valt er dus op de desktop weinig te winnen door de controller te verplaatsen.

Daarnaast kan Intel het zich (in tegenstelling tot AMD) permiteren voor de verschillende markten echt andere chips te ontwerpen. Als het voor desktops niet zinvol is om de controller te verplaatsen doet Intel het niet. Maar als het (ooit) zinvol wordt om de controller te verplaatsen is er ook geen fundamentele reden om het niet te doen.

Ondertussen lopen de verschillende soorten computers duidelijk uit elkaar. Een 4 weg xeon wordt heel anders gebruikt dan een mobiele T5500. Dan is het ook logisch dat je andere technieken toepast.

[Verwijderd]

Als AMD niet met wat nieuws op de proppen komt zal een groot deel van de servermarkt die ze hebben verovert weer terugvallen in de handen van Intel denk ik. Maar zoals de nieuwspost zegt zullen ze inderdaad ook niet stilzitten

[Chatslet]

aldus The Inquirer.....

[Verwijderd]

2 kleine verwarringen in een verder zeer interresant artikel.

in de tekst staat

Dit hoeft overigens niet te betekenen dat de fsb in zijn huidige vorm blijft bestaan: een voor de hand liggende optie is dat men overstapt op een seriële verbinding met de chipset, zoals toekomstige Xeons en Itaniums met elkaar zullen communiceren.

dit is een beetje verwarrend omdat de Xeon en de Itanium compleet verschillende architecturen zijn, is het zeer onwaarschijnlijk dat je een Xeon en Itanium op dezelfde chipset zult tegenkomen. uit het verhaal lijkt de suggestie te komen dat je Xeon en Itaniums zijn te mixen op dezelfde chipset.

2e punt is dat in het lijstje wat er onderstaat slechts 1 amd systeem wordt genoemd wat de suggestie wekt dat alle amd systeemen een max van 12,7GB hebben. het grote voordeel is van een geintegreerde geheugen controller is juist dat de snelheid toeneemt met het aantal sockets. die 12,7GB/s slaat dus op het enkele socket niet op amd systemen in het algemeen.

verder zou het me verbaasen als intel voor een geintegreerde geheugen controller op de extreem edities zou gaan omdat dit duidelijk de compatibiliteit zou breken met de normale serie's of je krijgt dan een soort van tandem configuratie wat juist de latency's alleen maar erger maakt.

vooral als het aantal core's toeneemt wordt een geintegreerde geheugen controller steeds belangrijker en zoals ook laatst in het artikel over de 16core opteron te lezen was is het een best probleem om alle core's van voldoende informatie te voorzien binnen aanzienlijke latencie's.

ik denk daarom dat het een kwestie van tijd is want intel kan geen octo-core voor desktop brengen en als de groei niet uit de breedte komt moet deze uit de hoogte komen.

[Fiander]

bij het plaatje staat anders duidelijk genoeg dat het de bandbreede per socket is.

betrefende de Opeteron, ik ben eerder nieuwschierig welke HT het is ? de nieuwe HT3 ?

[Wouter Tinus]

uit het verhaal lijkt de suggestie te komen dat je Xeon en Itaniums zijn te mixen op dezelfde chipset.

Dat is ook precies Intels plan: toekomstige Xeon MPs en Itaniums zullen op dezelfde moederborden geplaatst kunnen worden, wellicht zelfs tegelijkertijd.

Fiander:

betrefende de Opeteron, ik ben eerder nieuwschierig welke HT het is ? de nieuwe HT3 ?

Maakt niet uit, HT3 maakt de totale geheugenbandbreedte niet hoger, het wordt alleen makkelijker om gegevens die bij verschillende sockets horen uit te wisselen. Je kunt dus flexibeler zijn maar niet voor één processor meer bandbreedte rekenen zonder het bij een andere eraf te trekken.