Bug in AMD EPYC 7002 kan serverprocessor na 1044 dagen doen vastlopen

Een bug in de AMD EPYC 7002-serverprocessors kan ervoor zorgen dat een van de rekenkernen na 1044 dagen bedrijfstijd vastloopt. Volgens documentatie van AMD volstaat het om de server voor die termijn te herstarten. Het Amerikaanse bedrijf heeft geen fix gepland.

De redactie van Tom’s Hardware ontdekte de bug in de revisiegids van de EPYC 7002-serverprocessor die AMD in april heeft uitgebracht. Daarin staat te lezen dat een van de rekenkernen van de EPYC 7002 risico loopt om na ongeveer 1044 dagen vast te lopen omdat die dan niet meer uit de CC6-slaapstand kan ontwaken.

Volgens AMD hangt de exacte termijn onder meer af van de referentieklok waarmee de processor de tijd bijhoudt. Het Amerikaanse bedrijf stelt dat gebruikers de bug kunnen vermijden door de CC6-slaapstand van de EPYC 7002 uit te schakelen, of door hun server te herstarten voor de vooropgestelde termijn van ongeveer 1044 dagen bedrijfstijd. Over die termijn heerst op internet enige discussie. Volgens een Reddit-gebruiker zou de werkelijke termijn namelijk op ongeveer 1042 dagen bedrijfstijd liggen.

De redactie van Tom's Hardware meldt dat het niet ongebruikelijk is dat (server)processors bugs bevatten. Deze worden meestal opgelost, maar dat hangt volgens Tom's Hardware ook af van de ernst van de bug. Sommige bugs of kwetsbaarheden duiken volgens de redactie ook op na verloop van tijd en zijn hierdoor moeilijker op voorhand te voorspellen.

AMD heeft de EPYC 7002-serverprocessors in 2019 uitgebracht. Het bedrijf kwam toen met in totaal negentien processors van de EPYC 7002-serie. De processors zijn net als de Ryzen 3000-processors gebaseerd op de Zen 2-architectuur, met cpu-chiplets die op 7nm gebakken zijn.

Update, 11.45 uur: 'Het Amerikaanse bedrijf komt voorlopig niet met een fix.' in de inleiding is aangepast naar 'Het Amerikaanse bedrijf heeft geen fix gepland.'

AMD EPYC 7002-serverprocessors

Reacties (138)

[KeiFront]

De kans dat je deze bug triggered is wel zeer klein.

- Deep sleep state (cc6) is meestal standaard disabled en anders wordt het meestal disabled (power profile performance, ...).
- Een warme reboot reset de CPU, wat vermoedelijk al genoeg is om het probleem af te wenden.
- Constant patchen is veel belangrijker dan een hoge uptime, alle hardware en software bevat nu eenmaal butgs.
- Intel heeft ook bugs in hun C6 implementatie eentje die zelfs ieder moment kan optreden maar blijkbaar niet spectaculair genoeg voor een spectaculaire headline: ADL050

[Plofkotje]

Ik ben het opzich wel met je eens hoor, met als verschil dat Intel voor ADL050 een fix in hun microcode/BIOS code gedaan heeft, wat ze overigens ook zeggen op de link die je linkt AMD doet hier voorlopig nog niks mee, en geeft ook richting partners aan dat ze hier voorlopig niks mee gaan doen.

[thomas1907]

Het verschil is

ieder moment kan optreden

en

kan serverprocessor na 1044 dagen doen vastlopen

dat is bijna 3 jaar, de kans is sowieso al heel klein dat je server 3 jaar aan staat

[HakanX]

En als toevoeging, als je server cpu in diepe slaap kan gaan, heb je dus ook wel genoeg momenten waarop het niet gebruikt wordt en dus een keer opnieuw kan worden opgestart.

[Plofkotje]

Nouja, met VMware's quick reboot systeem bij het patchen zal het me niks verbazen als servers dat halen, terwijl de uptime van VMware ESXi kleiner is, terwijl mensen het niet doorhebben.

Met quick reboot wordt de CPU niet gereset, maar laadt ESXi een nieuwe kopie van zichzelf in zonder door de reset routine in de BIOS/UEFI te gaan. Dus wat dat betreft vind ik ze aardig vergelijkbaar.

[d3x]

Server firmware ga je dan nooit updaten????

[SilentDecode]

Want firmware updates bestaan niet....

Als je de boel GOED wil bijhouden, dan hoort daar regelmatig firmware updates doen, ook bij.
Vaak kan je de IPMI firmware wel on-the-fly doen, maar dat gaat niet gebeuren met een BIOS of een andere onboard controller, zoals de CLPD.

[YopY]

> Constant patchen is veel belangrijker dan een hoge uptime, alle hardware en software bevat nu eenmaal butgs.

True, maar idealiter kun je zaken 'hot replacen', van hardware tot software.

Aan de andere kant, dat is tegenwoordig met distributed computing weer minder, dan kun je een hele machine 'hot swappen'.

[wildhagen]

Het Amerikaanse bedrijf komt voorlopig niet met een fix.

Nee, wat is dat nou weer voor uitspraak? Niet sjiek, en dan druk ik me netjes uit.

Voor de mensen die wijzen op 'voorlopig': dat is NIET wat AMD in hun eigen PDF zeggen.

Daar staat niks over "Fix planned for future" of iets van die strekking, daar staat letterlijk "No Fix Planned", ze spreken dus nergens over 'voorlopig'. En "No Fix Planned" klinkt vrij permanent zeg maar.

Een uptime van 1044 dagen klinkt veel, maar het is niet ongebruikelijk dat hypervisors in datacenters, of specifieke high-availability clusters, dit soort uptimes wel halen in de praktijk. Niet elke server wordt wekelijks of maandelijks herstart.

Dat ze dan zeggen "pech klanten, we gaan het niet fixen, zoek zelf maar een oplossing om om de bug heen te werken" vind ik nou niet echt klantvriendelijk. Dat doet je reputatie in de servermarkt ook geen goed, want bedrijven zitten niet op dit soort zaken te wachten.

[Reactie gewijzigd door wildhagen op 22 juli 2024 16:15]

[Keeper of the Keys]

Een HA cluster haalt hoge uptime als geheel maar individuele nodes worden opnieuw opgestart dat is het hele idee van een HA cluster opzet dat de gebruiker/klant al die maintenance die gewoon belangrijk is te kunnen niet voelt.

Hoewel we "vroegah" het altijd leuk vonden om uptime te vergelijken en een zo hoog mogelijk nummertje te laten zien is de consensus nu eigenlijk behoorlijk omgekeerd, als je een systeem zolang niet opnieuw hebt opgestart dan heb je dus ook geen idee of het systeem als het dan toch gebeurt (al dan niet om software patches die niet live konden of doordat er echt iets mis ging) uberhaupt in een opstartbare staat is.

Je "hoge uptime" haal je door het systeem als geheel zo te bouwen dat er redundancies zijn en je overal maintenance kan uitvoeren zonder werk te onderbreken, op hypervisors verhuis je de guests naar andere hosts, SANs hebben meerede nodes en kunnen of de schijven van andere nodes aanspreken of hebben een kopie/genoeg parity informatie om de data te leveren, netwerk word dubbel uitgevoerd waarbij je in alledaags gebruik dus meer totaal throughput kan hebben en tijden maintenance de helft van je backbone reboot zonder dat iemand in de organisatie dat merkt etc.

[Reactie gewijzigd door Keeper of the Keys op 22 juli 2024 16:15]

[MMaster23]

Juist.. Ik heb bij meerdere grotere hosters gewerkt (en nu cloud scale).. Uptime is bijna een non compliance nummer geworden icm patching. Ja, we hebben steeds meer live patching van kernels etc maar dat neemt niet weg dat je ook firmware e.d. moet updaten.

Een cluster / cloud setup waar de individuele node niet boeit, is de setup van de toekomst. "treat servers like cattle, not pets" komt ook naar voren. Hup, workload eraf migreren dmv vm migratie of container spawning / orchestration en patchen/rebooten die hap.

Wanneer ik 3 jaar+ uptime hoor, begin ik wel beetje te schudden hoor.

[Guru Evi]

Tegenwoordig met een degelijk systeem kan alles wel live gedaan worden. Je kan alle patches via de IPMI of iDRAC of iLO interface “live” doen en livepatchen is vandaag de standaard.

Het is eigenlijk raar dat ik vandaag nog moet volledig rebooten op een server OS.

[praseodymium]

Ook bij iDRAC en iLO zijn reboots nodig om firmware updates daadwerkelijk te installeren. Het enige dat ‘live’ kan is de patches klaarzetten zodat ze bij de eerstvolgende reboot worden geïnstalleerd.

[Keeper of the Keys]

Live patch is leuk als je op dezelfde kernel branch blijft zitten en alleen security patches nodig hebt, maar zodra je GPUs en/of andere speciale hardware hebt of gewoon modernere features nodig hebt voor iets dan ga je echt wel rebooten voor updates zeker aan het begin van de product cyclus, er is ook altijd zat firmware die zelfs als je hem via IPMI live bijwerkt nog steeds een reboot vereist (bvb. Mellanox ConnectX NICs en eigenlijk elk apparaat met dual BIOS/firmware) voordat de nieuwe firmware ook echt in gebruik is, dus dan heb je de firmware "live" bijgewerkt maar draai je nog steeds de onveilige versie tot je reboot.
CPU microcode is nog zo'n leuke met alle CPU vulnerabilities die worden gevonden die "veilige" microcode wordt pas met een reboot in de CPU geladen.

En dan is je Linux/*BSD systeem voor het laatst geboot 5 jaar geleden en durft niemand meer in de buurt van het systeem adem te halen omdat niemand zeker weet of een reboot gaat werken, is een hardware upgrade (ie. migratie naar een nieuwe host) een totaal onbekende variable geworden.

Er is alweer een paar jaar geleden (>5 jaar als ik me niet vergis) een goed artikel geschreven over exact dit onderwerp door Facebook of Google, zoals iemand anders hierboven schreef je server moet een stuk vee zijn, compleet vervangbaar als er ook maar iets mee gebeurt en niet een huisdier, ik zet mijn nieuwe dingen uberhaupt zo op dat ik een playbook heb waarmee ik een lege server naar de gewilde state kan brengen en alleen de data nog een belangrijk verschil maakt.

[Reactie gewijzigd door Keeper of the Keys op 22 juli 2024 16:15]

[Guru Evi]

De nVIDIA enterprise drivers kunnen een update krijgen zonder reboot, moderne ConnectX en veel andere server kaarten kunnen ook een driver en firmware update krijgen doorheen het OS zonder reboot (enkel de verbinding herstarten). Intel heeft ook live patching voor microcode https://lore.kernel.org/[e-mail]/

Bijna alle firmware en drivers en kernels kunnen op een of andere manier live rebooten, dat was al jaren geleden de standaard voor oa. Sun hardware met Solaris maar Linux is ook redelijk gevolgd.

Er zijn enorm weinig redenen om nog door een volledige cold reboot te gaan.

[Cybje]

Wij rebooten juist maandelijks tijdens een maintenance window. Dan testen we meteen een failover en we weten dat het systeem correct opstart na een reboot. Over het algemeen geeft het geen downtime, want het is allemaal HA, maar we kondigen wel altijd maintenance aan.

Ik vind het zelf wel prettig, het heeft namelijk vertrouwen dat als er een keer een datacenter uitvalt ik gewoon lekker m’n wandeling af kan maken en niet met spoed achter de laptop moet

[Z80]

Bios en netwerkinterface updates kunnen niet live uitgevoerd worden. Niet bij Dell en niet bij HP.
De iDRAC of iLO zelf kan wel geüpdatet worden. Dit is een los staand OS. Voorheen op een aparte kaart, tegenwoordig onboard.

[kodak]

De AMD EPYC 7002 is niet alleen voor HA-clusters, maar juist voor verschillende toepassingen zoals zelfstandig gebruik. Daarbij is beschikbaarheid niet zomaar onbelangrijk omdat je een voorbeeld met clusters kan noemen. Het is eerder redelijker om het niet daarop maar te bagatelliseren. Dat doet namelijk geen recht aan het diverse gebruik, wat AMD zelf gepromoot heeft.

[Keeper of the Keys]

@kodak@flaskk
Ik heb ook thuis een servertje staan en ik accepteer dat als ik daar onderhoud aan doe ik downtime heb, voor dingen waar ik geen downtime mee wil hebben heb ik dan misschien nog een instance lopen bij een cloud provider of ik doe dat werk om een tijd dat het niets uitmaakt voor mij.

Het punt was dat een "lange" uptime over het algemeen behoorlijk onverantwoord is omdat dat dus betekent dat er (vrijwel) geen onderhoud is gedaan aan het systeem en je ook geen idee hebt of het systeem uberhaupt nog bootable is.

De meeste bedrijven die 5 negens uptime beloven/verkopen zullen dat ook absoluut niet op een enkele server doen maar op HA clusters (die eventueel wel in een enkel chassis kunnen zitten) en persoonlijk zou ik enorm sceptisch zijn van een bedrijf dat dat claimt te doen op een enkele machine zeker nu de gemiddelde server boottijd in minuten en niet seconden wordt geteld (en 5 negens geeft je minder dan zes minuten downtime per jaar).

Zelfs een bedrijf dat voor een dubbeltje op de eerste rang wil zitten moet nog steeds updates draaien etc. en HA hoeft helemaal niet zo duur te zijn, zeker een bedrijf dat voor dubbeltjes probeert te werken kan gewone desktop hardware gebruiken voor compute en alleen grote investeringen doen in storage zodat de data veilig is en de compute eenvoudig snel en goedkoop te vervangen.

[kodak]

Je doet kennelijk de aanname dat uptime belangrijk is om te concluderen of er goed onderhoud is gedaan. Dat is ongekeerd redeneren en eerder geen redelijk uitgangspunt. Na bijna 80 jaar aan zelfstandige systemen is dat onderhoud wel wat volwassener dan dat je perse down moet gaan. De uptime zegt dus niet zomaar iets over het onderhoud, hooguit dat er onderhoud is gedaan waarbij het nodig was om te herstarten of er andere omstandigheden waren. Daarbij is het niet aan AMD of ons om voor een ander maar te bepalen dat wat redelijke uptime is, of te oordelen dat die klanten om onderhoud dus maar niet goed bezig zouden zijn. Zeker niet als AMD geen interesse toont wat hun klanten voor belang hebben.

[SpamLame]

Same here, als ik een uptime van meer dan een half jaar voordat ik onderhoud uitvoer, doe ik std al en reboot voordat ik uberhaupt start met mijn werk. Geen zin in gedonder dan duurt het maar langer.

[flaskk]

Dat is voor bedrijf die genoeg financiële middelen heeft en het er voor overheeft prima. Maar in het echt heb je vaak bedrijven die dubbeltje op de eerste rang willen zitten en zolang de data redundant is, het allemaal maar prima vinden.

[beerse]

Bij de uptime van een operating systeem gaat het om de software. Wanneer is die voor het laatst opnieuw begonnen. Denk daarbij dat bij een herstart van elk systeem, de onderliggende 'hardware' niet herstart wordt! De hardware wordt in de regel pas herstart als de spanning er helemaal vanaf gaat en daarna weer onder spanning gebracht wordt.

De vraag is dus: Hoe uit en down moet zo'n cpu gaan om te 'resetten', om de 1044 dagen te doorbreken.

Toegegeven, een high-available, cluster of anders zins voor continuïteit ingericht systeem kan af en toe wel 1 node missen die daarbij wel herstart. En wat zijn 1044 dagen? Nog geen 3 jaar. Er is genoeg hardware dat 3 à 4 jaar aan staat en dan om economische redenen wordt vervangen.

[Keeper of the Keys]

Bij het doen van een reboot wordt alle hardware wel degelijk opnieuw geïnitialiseerd, op een moderne server ben je daardoor al gauw een paar minuten kwijt aan puur en alleen de hardware die zichzelf aan het checken is bij een boot/reboot.

Als ik het mij goed herinner is in de consumenten wereld op Windows met fastboot het zelfs zo dat reboot het enige is dat alles echt reset terwijl het "uitzetten" de hardware juist een heleboel state/driver wordt hersteld bij het weer aanzetten.

Je kunt het doen van een reboot uitstellen met hot-patches etc. maar uiteindelijk zijn er altijd wel updates die een volle/echte reboot zullen vereisen en dat zijn vaak ook de updates die het meest onverantwoord zijn om over te slaan.

[beerse]

Er is altijd een verschil tussen reboot en een power-cycle. Al is het alleen maar dat de bios/uefi weer echt bij 0 begint en met een schoon geheugen. En ja, een praktisch ingestelde server heeft dan met booten enige tijd nodig om alle hardware te controleren en initialiseren. Als mijn servers meer dan 1 week geleden zijn opgestart, draaien ze een volledige geheugen controle die rustig meer dan een kwartier duurt.

Natuurlijk, bij een herstart wordt de bios/uefi opstart routine weer doorlopen. Maar juist zaken die voor de cpu en de rest van de hardware belangrijk zijn blijven behouden. Denk daarbij, juist voor servers, ook aan remote-console zaken en dergelijke. Er gaat niets boven een echte power-down.

Voor het bijwerken van de oeps in deze cpu moet je dieper in het systeem dan de gemiddelde os-patch. Denk liever een firmware update/upgrade. Daarvoor moet ook de firmware worden herstart. Voor de firmware van de gemiddelde I/O kaart hoeft alleen dat deel maar herstart te worden. Maar om het os te laten draaien bij de update van de firmware van de cpu is toch wel een uitdaging.

[Keeper of the Keys]

Remote console draait op een apart systeem, tegenwoordig een onboard SoC op het moederbord maar die heeft verder niets te maken met de CPU van de server zelf, AMD geeft zelf aan dat een reboot voldoende is om de teller die deze bug veroorzaakt te resetten.
Vorig jaar moest ik nog steeds een volle reboot doen om de nieuwe firmware op mijn Mellanox kaarten actief te laten worden, ik kon de firmware live upgraden maar de nieuwe firmware werd pas actief na een reboot en hetzelfde geldt voor zover ik ken voor de meerderheid van firmwares/microcode.

[Zackito]

Dat zou ik juist niet verwachten. Hypervisors moeten ook gewoon gepatcht worden als ook de firmware van je servers.

In een datacenter verwacht je dat er genoeg capaciteit is en al helemaal bij een “HA cluster” om dit zonder downtime uit te kunnen voeren.

Ik zou dit enkel verwachten bij een klant met niet genoeg resources of zonder systeembeheerder.

[YoMarK]

Vmware doet al een flinke tijd bij patches (remediation) overigens by default op ondersteunde hardware een 'quick reboot'. Die gaat niet door POST heen, maar doet een snelle reload van het OS. (ik heb zo het vermoeden dat dit niet afdoende gaat zijn om deze 'timer' te resetten).
Het lijkt me dat er nog wel eens plekken zijn waar het mis zal gaan de komende tijd.
Oplossing is dan dus om deze feature uit te zetten, en de server een volledige reboot cyclus te laten doorlopen(+5 minuten wachttijd per host).

[Blokker_1999]

Maar met rolling upgrade/reboot functionaliteit zou dat niet mogen uitmaken. Je start dat process en kijkt af en toe eens of alles goed gaat. Of het nu 2h of 20h kost om af te ronden maakt niet eens uit.

[Guru Evi]

Deze dagen (sinds Solaris) kunnen patches ook zonder reboot. 1000 dagen klinkt veel maar bij oa HPC clusters en embedded systemen is dit niet veel, die rebooten nagenoeg nooit, het OS dat je had in het begin is nog steeds het OS dat je vandaag draait een upgrade is een grote taak.

[Keeper of the Keys]

In mijn ervaring worden nodes van HPC clusters constant gereboot, dat was juist het heerlijke van werken in een omgeving met zo'n cluster, als je maintenance wilt doen of updates wil doorvoeren kun je makkelijk een paar voorbeeld nodes drainen om mee te testen en laat je daarna nodes rebooten zodra hun huidige jobs afgerond zijn afhankelijk van de runtime limiet kan zo'n cyclus wel langer dan "normaal" duren (wij stonden jobs van maximaal 30 dagen toe).

Ook voor de jobs zelf als die goed opgebouwd zijn kunnen die zelfs doorstarten op een andere node zonder (veel) werk te verliezen als er iets mis is met de node waar ze op draaien of de update die moet worden doorgevoerd dringend is.

[Blokker_1999]

Bij HPC clusters moet je uitval van nodes kunne tolereren, en embedded systemen zullen niet snel op dit type CPU draaien.

[Zer0]

Het Amerikaanse bedrijf komt voorlopig niet met een fix.

Er wordt nergens gezegd dat er geen fix komt, en een fix fantaseer je ook niet zomaar, daar gaat soms tijd in zitten.

[wildhagen]

In de PDF van AMD staat "No Fix Planned".

Juist dat voorlopig wat in dit artikel staat wordt nergens door AMD vermeld, dan had er wel iets als "Fix planned in future" of iets van die strekking gestaan. "No fix planned" klinkt eerder vrij permanent.

[downtime]

Een plan kun je elke dag weer veranderen. Eigenlijk geldt hetzelfde als er "Fix planned" stond, ook dat plan kan morgen weer veranderen, bijvoorbeeld omdat klanten zich erover opwinden. Dus in die zin is het allemaal maar voorlopig.

[TheVivaldi]

Het wordt nergens gezegd, behalve dan in hun eigen berichtgeving:

https://www.amd.com/system/files/TechDocs/56323-PUB_1.01.pdf

Tweakers heeft hele goede redacteurs, maar dit lijkt me toch gewoon een foutje in het artikel. Ik bedoel: ik mag toch aannemen dat het bedrijf in de eigen communicatie geen onjuiste informatie publiceert.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 16:15]

[Zer0]

This section documents product errata for the processors.
Dit document beschrijft wijzigingen aan de processor, en de fix kan heel goed via software/microcode komen (dat is zelfs waarschijnlijker, aangezien het lastig is bestaande processoren aan te passen)
Dus ja, er zijn geen wijzigingen aan de CPU in de planning, maar dat betekent niet dat er geen oplossing komt in een andere vorm.

[TheVivaldi]

Oké, maar het betekent ook niet dat er “voorlopig” is gezegd, want zoals je kunt lezen heeft AMD daar geen uitspraak over gedaan.

[RJG-223]

Dit document beschrijft wijzigingen aan de processor, en de fix kan heel goed via software/microcode komen (dat is zelfs waarschijnlijker, aangezien het lastig is bestaande processoren aan te passen)

Te meer waarschijnlijk, omdat het probleem zeer waarschijnlijk ook in de microcode zit. Het is echt niet een electrisch draadje of een transistortje dat het na ruim duizend dagen niet meer trekt, en een reboot nodig heeft...

[jochemd]

Ze bieden toch een alternatief: schakel C6 uit. Allways-on systemen hebben meer aan dat alternatief dan aan een microcode update waarvoor het systeem geherstart moet worden voor installatie.

[field33P]

Dat betekent wel een hoger energieverbruik voor elke keer dat een node op idle staat, en daar zitten datacenters waarschijnlijk ook niet op te wachten. Die proberen juist hun energierekening zo laag mogelijk te houden.

[Tomatoman]

Dan pak je het andere alternatief: na krap 3 jaar gewoon een keer een reboot. Laten we niet te dramatisch doen over een probleem dat slechts zeer weinig gebruikers treft (want een uptime van 3 jaar is niet gebruikelijk en volgens velen zelfs onwenselijk) en bovendien gemakkelijk te voorkomen is.

[Boxman]

Als je cluster zo vaak op idle staat dat je dat gaat merken in de stroomverbruik, heb je blijkbaar meer dan genoeg idletijd voor 1x per 2.5 jaar rebooten.

[field33P]

Ook voor korte (lees: 1 seconde oid) idles kan je snel naar C6 overschakelen, het kost namelijk nauwelijks tot geen tijd om eruit te ontwaken maar het scheelt wel een paar watt.

[Triblade_8472]

Dit is de tekst van Tweakers, niet AMD!

Als je de bron leest staat er "no fix planned". Effectief weinig verschil, maar in ieder geval correct.

Als ik het goed begrijp is het een hardware issue En kúnnen Ze het niet eens fixen zonder de cpu te vervangen. En dan nog, het komt dusdanig regelmatig voor in cpu's dat je ze dan niet eens meer hoeft te verkopen omdat je ze dan altijd gratis moet weggeven.

Wellicht niet geweldig, maar wel hoe het leven op dit moment werkt. Het is gewoon té klein/ingewikkeld blijkbaar om 100% betrouwbaar te krijgen.

"
AMD says the timing of the failure could vary based on the spread spectrum and REFCLK frequency, the latter of which is the reference clock that helps the chip keep track of time.
"
Klinkt als een niet fixable probleem als ik het zo lees.


En even serieus, bijna 3 jaar uptime is in deze tijd hoog. Met alle virtualisatie en failovers mag het echt geen probleem meer zijn zaken te herstarten.

[RJG-223]

"
AMD says the timing of the failure could vary based on the spread spectrum and REFCLK frequency, the latter of which is the reference clock that helps the chip keep track of time.
"
Klinkt als een niet fixable probleem als ik het zo lees.

Wat mij betreft klinkt het meer als een overflow in een tellertje die niet goed afgehandeld wordt. Prima fixable, maar niet de moeite waard. Misschien is het zelfs iets complexer dat dat, zodat de fix net niet triviaal is. Misschien is het een kapot register ergens, waarvoor in microcode een workaround gemaakt moet worden, die dan weer een performance-impact heeft. Allerlei mogelijkheden, en zeer waarschijnlijk prima te fixen. Maar fixen is niet gratis. Dat kost tijd, en dus geld. En er moet daarna ook uitgebreid getest worden. En dan heb je dus nog een mogelijke performance-consequentie.

Zet dat tegenover het feit dat het maar eens in de drie jaar gebeurt, als de CPU zo lang niet gereboot is, wat zeer onwaarschijnlijk is. En de tweede keer is dan zes jaar later. En de derde keer 10 jaar later, en dan zijn de meeste van die processoren waarschijnlijk al met pensioen. Geen erg goede businesscase voor een fix...

[Zyppora]

[...]

Een uptime van 1044 dagen klinkt veel, maar het is niet ongebruikelijk dat hypervisors in datacenters, of specifieke high-availability clusters, dit soort uptimes wel halen in de praktijk. Niet elke server wordt wekelijks of maandelijks herstart.

Een uptime van 1044 dagen is 3 jaar. Ik neem aan dat er in die 3 jaar vast wel maintenance wordt uitgevoerd, zoals patches installeren op het host OS etc. Ik weet niet hoe het er in een datacenter aan toe gaat, maar high-availability clusters lijken me juist geen last te hebben van het trapsgewijs cyclen van hardware; als er eentje plat gaat, neemt de rest van de servers het werk simpelweg over.

Dat ze dan zeggen "pech klanten, we gaan het niet fixen, zoek zelf maar een oplossing om om de bug heen te werken" vind ik nou niet echt klantvriendelijk. Dat doet je reputatie in de servermarkt ook geen goed, want bedrijven zitten niet op dit soort zaken te wachten.

Waarom zo selectief lezen? Er wordt gezegd dat ze voorlopig niet met een fix komen, wat impliceert dat die er uiteindelijk wel zal komen, en de 'oplossing om om de bug heen te werken' staat ook gewoon letterlijk in het artikel:

"Het Amerikaanse bedrijf stelt dat gebruikers de bug kunnen vermijden door de CC6-slaapstand van de EPYC 7002 uit te schakelen, of door hun server opnieuw op te starten voor de vooropgestelde termijn van ongeveer 1044 dagen bedrijfstijd."

[TheVivaldi]

Het is eerder jíj die selectief leest, want in hun eigen berichtgeving gebruikt AMD het woordje “voorlopig” niet en staat er gewoon duidelijk “no fix planned”.
https://www.amd.com/system/files/TechDocs/56323-PUB_1.01.pdf

[JayStout]

Ik heb het artikel aangepast op basis van de feedback.

[TheVivaldi]

Top, bedankt, Jay! En ook aan @wildhagen voor het in eerste instantie grondig doorlezen van dit document!

[RJG-223]

Het is eerder jíj die selectief leest, want in hun eigen berichtgeving gebruikt AMD het woordje “voorlopig” niet en staat er gewoon duidelijk “no fix planned”.
https://www.amd.com/system/files/TechDocs/56323-PUB_1.01.pdf

'No fix planned' is exact hetzelfde als 'voorlopig geen fix'. Anders was er een plan geweest, had er gestaan: 'fix komt pas over twee jaar' of zoiets. 'Voorlopig niet' betekent namelijk precies dat er geen (concrete) plannen zijn voor het uitbrengen van een fix.

Nu ben ik met je eens, dat de interpretatie van @Zyppora ook niet klopt. 'Voorlopig niet' impliceert NIET dat het er uiteindelijk wel zal komen. Het impliceert alleen 'nu nog niet, misschien later'. Het enige wat we dus kunnen zeggen, is dat er geen fix gepland is, maar dat er ook nog niet is besloten om dat nooit te gaan plannen.

[SkyStreaker]

De zin is ook wat kort door de bocht en verdiend wat ruimer denken, want onder welke omstandigheden komen ze voorlopig niet met een fix? De uitspraak "onder meer" laat tevens teveel ruimte. Moet er microcode zodanig aangepast worden dat er rigoreus getest moet worden? Zeker op dit niveau van gebruik kan ik mij dat goed voorstellen. Kan het ook verholpen worden of moet er een nieuwe hardware revisie komen?

Zegt de redacteur dat onhandig of is het een quote? Het wordt zelfs nog genuanceerd ook:

De redactie van Tom's Hardware meldt dat het niet ongebruikelijk is dat (server)processors bugs bevatten. Deze worden meestal opgelost, maar dat hangt volgens Tom's Hardware ook af van de ernst van de bug. Sommige bugs of kwetsbaarheden duiken volgens de redactie ook op na verloop van tijd en zijn hierdoor moeilijker op voorhand te voorspellen.

Daar moeten we ook niet overheen gaan lezen, toch?

[Reactie gewijzigd door SkyStreaker op 22 juli 2024 16:15]

[i-chat]

want bedrijven zitten niet op dit soort zaken te wachten.

hoeveel bedrijven ken die servers draaien met een uptime van meer dan 1000 dagen? en bedoel ik als in kennen op een manier dat je er ooit zelf bij betrokken bent geweest bijvoorbeeld klanten, (voormalig) werkgevers ...

enkele van de bedrijven waar ik ooit rondgelopen heb hadden bedrijfscritische databases die absoluut moesten blijven draaien, maar die toch, ondanks hot-patching van het OS, 1x per jaar down gingen voor onderhoud. voor wie uptime belangrijk is, regelt men zich toch al gewoon clustering in en dan is het down gaan van één enkele node. hooguit een kleine irritatie. kom op het gaat hier over een bug die zorgt dat je niet uit cc6 komt en die je daadwerkelijk kunt voorkomen door 1x per +/- 34 maanden. het systeem te rebooten.

[wiseger]

Meeste data centers doen wel jaarlijks disaster recovery oefeningen. Verder heb je ook weleens patches die een reboot vereisen.
Wellicht niet netjes maar ik denk niet dat er velen tegen de 1044 dagen uptime aanlopen.

[mdcoo]

Met huidig patch beleid gaat die 1042 dagen een uitdaging worden, in zekere zin dus geen probleem. Ik schat in dat alleen embedded systemen met deze processoren wellicht seze bug een probleem gaat worden.

[RJG-223]

Met huidig patch beleid gaat die 1042 dagen een uitdaging worden, in zekere zin dus geen probleem. Ik schat in dat alleen embedded systemen met deze processoren wellicht seze bug een probleem gaat worden.

Welke embedded systemen ? Dat soort systemen gaat ook af en toe uit voor onderhoud. Al is het enkel een software-upgrade. Maar het kan ook mechanische slijtage zijn van de machine, waardoor een onderdeel vervangen moet worden, en de machine dus uit moet. Of gewoon het (verplichte) jaarlijkse onderhoud van de leverancier...

[k995]

Daar staat niks over "Fix planned for future" of iets van die strekking, daar staat letterlijk "No Fix Planned", ze spreken dus nergens over 'voorlopig'. En "No Fix Planned" klinkt vrij permanent zeg maar.

Neen "No fix planned"= "geen ingeplande oplossing" dat wil niet zeggen dat er niet ooit 1 komt wel dat er momenteel niet aan gewerkt word noch dat dit gepland is.

Dat ze dan zeggen "pech klanten, we gaan het niet fixen, zoek zelf maar een oplossing om om de bug heen te werken" vind ik nou niet echt klantvriendelijk. Dat doet je reputatie in de servermarkt ook geen goed, want bedrijven zitten niet op dit soort zaken te wachten.

1044 dagen van iets niet herstarten is toch echt niet verstandig imho.

[field33P]

Neen "No fix planned"= "geen ingeplande oplossing" dat wil niet zeggen dat er niet ooit 1 komt wel dat er momenteel niet aan gewerkt word noch dat dit gepland is.

De meest voor de hand liggende verklaring is dat het een hardware bug is die niet met een microcode-update valt op te lossen.

[k995]

Dat zou goed kunnen , of dat het zo complex is dat ze geen idee hebben hoe het op te lossen.

[Richo999]

1044 dagen betekent net geen 3 jaar, de reden om dit niet the fixen vanuit AMD kan ik begrijpen omdat dit een zeer specifiek big us en waarschijnlijk veel kost om te fixen. Neem toch aan dat servers minimaal elke 1-2 jaar herstart worden voor security updates?
Ja zou gefixed moet worden, maar denk dat deze gefixed word in hun volgende generatie.

[CAPSLOCK2000]

Een uptime van 1044 dagen klinkt veel, maar het is niet ongebruikelijk dat hypervisors in datacenters, of specifieke high-availability clusters, dit soort uptimes wel halen in de praktijk. Niet elke server wordt wekelijks of maandelijks herstart.

Ik vind het ook niet netjes van AMD maar het is tegen alle best-practices in om je systemen zo lang achter elkaar te laten draaien zonder reboot. Ik weet dat er specifieke situaties zijn waarin het gevraagd wordt maar eigenlijk is het gewoon geen goed ontwerp.
Als je systemen zo belangrijk zijn dat ze niet down mogen dan moet je zorgen voor redundantie of een andere manier om fouten op te vangen want die zullen altijd optreden.
Juist in de hypervisor wereld zijn er een hoop vormen van high-availability en online-migratie om daar mee om te gaan.

[supersnathan94]

Ligt heel erg aan je systeem denk ik. Als ik een systeem tegenkom met een uptime van meer dan 6 maanden heb ik ernstige twijfels bij patch en update management. Maar wij zitten dan ook voornamelijk op HA clusters waarbij de individuele nodes behandeld worden als “cattle”. Maximale uptime van dergelijke machines is normaliter 2 tot 4 weken en soms zelfs maar enkele uren bij pieken.

1044 dagen is ruim 2,5 jaar. Dat is voor onze ideale situatie dus echt veel te veel. Dan is de kans groot dat je hele belangrijke patches gewoon kompleet gemist hebt.

Uptime van onze diensten zit hem dan ook in redundantie, load balancing en stateless computing. Je kunt naar 1 van de tig instances op willekeurige locaties gestuurd worden zonder dat je dit door hebt. 100% uptime is een utopie, maar 99,99% is prima haalbaar.

[jetspiking]

Inderdaad, duizenden euro's betalen voor een premium CPU en vervolgens falende hardware krijgen waarbij de oplossing is om je server maar iedere 10xy dagen te herstarten. En als je dan te laat bent heb je maar gewoon pech, dag rekenkern?

[Reactie gewijzigd door jetspiking op 22 juli 2024 16:15]

[SkyStreaker]

Helaas zijn wij uiteindelijk ook maar mensen en je kan er dan nog zoveel op los laten qua QA, je creeërt nooit geen absoluut in je testomgeving. Dat ambieer je omdat zo goed mogelijk te bereiken. Dus ja, er is een bug ontdekt en daar ga je naar acteren in onderzoeken in hoeverre mate je dit kan of gaat oplossen.

Een bedrijf die dit gebruikt voor service-verlening weten van zichzelf dat ook zìj niet zonder menselijk falen zitten, met bijv. hun duizenden euro's vragen voor service-verlening.

[Reactie gewijzigd door SkyStreaker op 22 juli 2024 16:15]

[i-chat]

besef je je wel dat je hier dus praat over systemen die bijna 3 jaar lang continu aan moeten staan,

even ter indicatie: alle windows machines vallen dus al af, en voor de rest geldt dat het zou moeten gaan om systemen die Niet in een cluster hangen (want in een cluster is het geen enkel probleem om 1x per 2jaar (dat is iets makkelijker in te stellen met cron), je losse nodes een reboot te geven.

dit gaat echt alleen maar problemen geven voor zeer specifieke use-cases en ja dan is het natuurlijk zuur, maar het is zoeker ook niet de eerste keer dat een cpu bug voor problemen zorgt bij zulke bedrijven.

[downtime]

Ik snap de opwinding niet. Voor een vliegtuig betaal je soms honderden miljoenen en ik kan me herinneren dat één of ander vliegtuigtype ook last had van een crashende computer na een bepaald aantal vlieguren. Fix: Voor die tijd het systeem even rebooten. Dat is een prima oplossing als het probleem zich maar eens in de zoveel jaar voordoet en je het simpel op kunt lossen met een jaarlijkse reboot ofzo.

[680x0]

Inderdaad, duizenden euro's betalen voor een premium CPU en vervolgens falende hardware krijgen waarbij de oplossing is om je server maar iedere 100x dagen te herstarten. En als je dan te laat bent heb je maar gewoon pech, dag rekenkern?

En u kan ons dan nu even een lijstje geven met servers en services die stuk voor stuk gedurende 2,5 jaar volledig 100% uptime hebben?

[Guru Evi]

RHEL clusters, VMWare clusters, HPC clusters. Eenmaal Proxmox met live patching komt denk ik ook nooit te hoeven rebooten op een degelijk systeem dat nu al de BIOS en firmware live kan patchen.

[Z80]

Dat zijn clusters. Niet 1 stuk hardware. En het probleem zit in 1 server, waarvan dit type mogelijk meedere in het zelfde cluster zitten en 1 voor 1 een reboot kunnen krijgen. Het cluster gaat dus niet onderuit.
Blijft de vraag van 680x0 staan.

[Guru Evi]

De individuele nodes herstarten niet vanwege live patching en in HPC herstart je niet want het hele systeem zit achter een jump box.

[watercoolertje]

Elke 100 dagen? Elke 1000 dagen toch?

[jetspiking]

Klopt, ik had eigenlijk moeten stellen iedere "10xy" dagen. Dat heb ik aangepast in mijn reactie, dankjewel.

[Sinester]

En als je dan te laat bent heb je maar gewoon pech, dag rekenkern?

Je bedoeld als je te laat bent heb je totaal falende server administrators en heeft je systeem al bijna 3 jaar geen updates meer gehad

[Z80]

Even 1 aanpassing in het systeem en de problemen zijn verdwenen. Staat gewoon de tekst. Maar lezen is blijkbaar moeilijker dan reageren.

Het Amerikaanse bedrijf stelt dat gebruikers de bug kunnen vermijden door de CC6-slaapstand van de EPYC 7002 uit te schakelen,

[jetspiking]

Is het nu écht zo moeilijk om op een gewone en constructieve manier te reageren? Los van dat je punt overigens niet correct is.

"CC6-slaapstand van de EPYC 7002 uit te schakelen" is geen oplossing. Dat is een workaround die een functie opoffert om ernstige problemen in de toekomst te voorkomen.

[Verwijderd]

En een slaapstand is nodig op een server die perse 24/7 moet draaien? En nooit even mag rebooten? Of is dit een ander soort slaapstand?

[heuveltje]

Dit is het in slaapstand zetten van individuele cores/gedeeltes van de CPU
niet heel de server
En juist op een Dikke server CPU wil je die slaapstanden, want vaak heb je een paar uur piekbelasting, en de rest VEEL minder gebruik, dus scheelt flink in verbruik.

[Reactie gewijzigd door heuveltje op 22 juli 2024 16:15]

[Argantonis]

Er staat dat ze VOORLOPIG niet met een fix komen.
Aangezien deze processoren in april uitgebracht zijn, zal dit dus op z'n vroegst voor 't eerst ook rond april 2026 voor gaan komen. Ze hebben dus nog wel ff.

[wildhagen]

Er staat dat ze VOORLOPIG niet met een fix komen.

Daar hebben getroffen bedrijven helaas weinig aan, die zitten dan met een crashend systeem tot die tijd...

Aangezien deze processoren in april uitgebracht zijn, zal dit dus op z'n vroegst voor 't eerst ook rond april 2026 voor gaan komen. Ze hebben dus nog wel ff.

Ehm. Nee. De revisiegids is in april uitgegeven. Deze processoren zijn uit 2019.... staat ook letterlijk in het artikel:

AMD heeft de EPYC 7002-serverprocessors in 2019 uitgebracht.

[Boxman]

Je kunt ook overdrijven natuurlijk. De bandaid-fix is een eenmalige reboot en dan kun je weer bijna 3 jaar in afwachting van de volledige fix. Dat is van een totaal ander kaliber dan “met een crashend systeem zitten”

[Rctworld]

Misschien dat er daarom ook geen fix komt. Als je voor die fix firmware/microcode moet updaten en rebooten dan zitten de meeste servers ook zonder fix met nog eens 3 jaar aan de “maximale levensduur” voor een gesupport productie cluster.

De mensen die actief updaten die lopen er toch niet tegenaan. En de mensen die niet willen rebooten die zijn er dan ook niet bij geholpen. Want met 1 reboot zonder firmware update zijn ze net zo ver.

[Guru Evi]

Het probleem is dat een enkele core eruit gaat zonder het hele systeem te crashen. Dus als de core aangewezen is aan een VM dan gaat die VM crashen maar de rest van het systeem draait door.

Dat is zo’n bug waar je je haar van uittrekt omdat het systeem denkt dat er een core is maar elke keer die core wordt gebruikt gaat de VM ervan onder.

Dan moet je alsnog een anders stabiel systeem herstarten en dan gaat het probleem weg voor 2.5 jaar.

[Sinester]

Dan moet je alsnog een anders stabiel systeem herstarten en dan gaat het probleem weg voor 2.5 jaar.

Hoe stabiel en veilig was het systeem al als je er 2,5 jaar letterlijk niks mee gedaan hebt?

[Zer0]

Daar hebben getroffen bedrijven helaas weinig aan, die zitten dan met een crashend systeem tot die tijd..

Ja, elke 2,8 jaar..... Natuurlijk is het niet prettig, maar het is ook weer niet zo dramatisch als een server die vaak vast loopt.

[dabronsg]

De processor is uit 2019. We zijn vier jaar verder en we maken ons hierover druk omdat AMD dit zelf naar buiten brengt. Niet omdat er overal servers aan het omvallen zijn.

Volgens mij valt het dus wel mee.

Nu vraag ik mij af of mijn 3900x ook deze bug heeft. Met een gemiddelde uptime van 8 uur...

[Reactie gewijzigd door dabronsg op 22 juli 2024 16:15]

[Cergorach]

Dat zou wel kunnen, maar aangezien het maar eens in de 1044 dagen voorkomt zou een IT engineer nooit echt fatsoenlijk kunnen troubleshooten. Dat AMD dit nu naar buiten brengt komt waarschijnlijk omdat er verschillende klanten bij hun hebben aangeklopt met dit issue.

[dabronsg]

Maar wie in deze community heeft er last van gehad?

We hebben hier heel veel beheerders rondlopen...

[uiltje]

Een vastlopende server is nou niet bepaald schokkend. En als je dan geen zinnige trace ervoor hebt dan ga je er niet achter komen wat er aan de hand is. Dus deze bug kan wel degelijk voorkomen, maar niet worden gedetecteerd laat staan gemeld.

[Frame164]

Grappig hoe dit nu wordt gedownplayed, wrs omdat het over AMD gaat. Als het een probleem bij Intel was geweest was het bedrijf hier ongetwijfeld compleet afgebrand.

[Zer0]

Of het wordt "gedownplayed" omdat het werkelijk niet een heel impactvolle bug is, en niet alles een AMD vs Intel discussie hoeft te worden..

[Keypunchie]

Als jij als bedrijf niet om kan gaan met een geplande server herstart eens in de 3 jaar… dan draai je toch al niets kritisch… (hoop ik)

[Argantonis]

Ahh ok, verkeerd gelezen! Maar goed, dan nog, ze zeggen niet 'we gaan het niet fixen', ook in dit artikel staat 'voorlopig niet'. Het kan goed dat het een behoorlijk lastig probleem is.

Edit: al zie ik nu in het bronartikel dat 'voorlopig' niet wordt genoemd.
Edit 2: in de revisiegids zelf staat gewoon dat er geen fix gepland is. Maar niet dat het per se nooit gefixed gaat worden. Zowel Tom's hardware als Tweakers hadden dus wat nauwkeuriger kunnen zijn.

[Reactie gewijzigd door Argantonis op 22 juli 2024 16:15]

[Triblade_8472]

Zie m'n comment hieronder. Er staat in de bron zelfs "no fix planned".

[SuperDre]

De fix is de slaapstand uit zetten. Nou weet ik niet of daar een reboot voor nodig is, zoja, dan vraag ik me af of je dan niet net zo goed elke 2.5 jaar de server eens een keertje te rebooten.

[Polderviking]

Ben het aan een kant wel met je eens dat dit gewoon gepatcht moet worden.

Maar wie loopt hier in de praktijk tegen aan?

Binnen die kleine drie jaar waarin dit optreed moet je echt wel iets updaten waardoor die machine een slinger moet krijgen.

En dingen als High Availability virtualisatieclusters zijn er juist op inrecht zodat nodes (servers) kunnen uitvallen zonder dat er productieverlies optreed.
De uptime van zo'n cluster is in die zin dus "nep" omdat de individuele nodes die dat cluster dragen echt wel een paar keer rebooten in een doorsnee jaar.

[WillySis]

Men heeft geen plannen voor een fix, maar dat betekend niet dat er geen fix komt. "Zoek zelf maar een oplossing heen" is ook niet waar, want men geeft zelfs twee mogelijkheden om om de bug heen te werken: Voor die tijd opnieuw opstarten, of de cc6 slaapstand uitschakelen.

Even in perspectief zetten: Daar 1044 dagen bijna drie jaar is, is een herstart binnen die tijd beslist niet uitzonderlijk. Zelfs in het extreme geval dat een server die tijd blijft draaien, zal er maar één keer een herstart nodig zijn. Tegen de tijd dat er een tweede herstart nodig is is de server al afgeschreven.

[d3x]

Ongebruikelijk? ooit al gehoord van security en patch management? Je gaat je systeem / platform sowieso in een X maanden patch cycle zetten, al of niet firmware of OS wise. Het gehele platform zal in deze cyclus dan ook garanderen dat er geen downtime is (als je iets wat degelijk opzet tenminste...)

Dit is nu eens weer een echte storm in een glas water.

[hellred666]

Maar wat als er een fix komt waardoor je het systeem opniew moet opstarten? Dan is zonder fix maar gewoone een restart toch net zo handig. De kans dat je 2x tegen deze bug aanloopt is wel echt zeer klein (meer dan 5,5 jaar tijd heb je daar voor nodig).

[adslfreak]

als je in de tussentijd dan geen updates/ bugfixes loslaat op je systeem ben je ook niet goed bezig. In deze tijd is een hele lange uptime lang niet altijd meer zaligmakend.

[Luno]

Heb je een fix (hoop je) moet je 1044 dagen wachten om te weten of ie echt werkt.

[Verwijderd]

Men kan vast wel een prikje vinden om een reboot in eens in de 2.8 jaar te voltooien.

Heb ook servers en de maximale uptime tijd was bijna 2 jaar. Voor mij geldt een goed gepatchte 100x de voorkeur ipv een uptime dingetje waar je niks aan hebt.

[WhiteDog]

Wat heeft "goed gepatcht" met uptime te maken? Een beetje degelijk OS is anno 2023 te matchen zonder power cycle 😝

[Polderviking]

Zoals welk OS bijvoorbeeld?
Voor alsnog vraagt alles wat ik in mijn day to day gebruik, waaronder Windows en divserse Linux distributies nog om een reboot als er bepaalde componenten bijgewerkt worden.

Het is daarbij ook wel mooi om te weten dat je server nog reboot uberhaupt. Zelfs al zou je oprecht niet hoeven herstarten.
Niet dat er 6 patch rondes geleden wat kapot is gegaan en je er bij bijvoorbeeld een stroomuitval op een ongunstig moment pas achter komt dat je server niet terugkomt terwijl er honderd mensen niet kunnen werken.

Hoge uptimes zijn in de praktijk vooral een rode vlag die wijzen op niet onderhouden servers.

[Reactie gewijzigd door Polderviking op 22 juli 2024 16:15]

[supersnathan94]

Firmware en UEFI patches alleen niet altijd.

Dingen zoals Intel management engine disablen, spectre en meltdown patches, updates van bios/uefi en soms ook disk firmware heeft vaak een reboot nodig.

In een goede applicatie omgeving met een cloud first strategy zou een server uptime van meer dan een paar weken ook geen goede zaak zijn. Je mist dan gewoon belangrijke patches en veelal is je architectuur niet goed bestand tegen wegvallen van een node bijvoorbeeld.

Voor on-premises waar patches ingeboekt werden en je met maintenance windows kan werken was het een ander verhaal, maar voor cloud first moet je gehele applicatie er gewoon voor gebouwd worden met failsafes en redundancy. Leuk klusje, maar absoluut de moeite waard.

Daarnaast wil je ook gewoon om de zoveel tijd een cold boot scenario uitvoeren. Al was het maar als test om te zien of je spul door blijft draaien.

[CAPSLOCK2000]

Ik zie een hoge uptime tegenwoordig als een teken van slecht beheer.

Die systemen lopen vaak ook achter met patches installeren (en activeren!) en er is ieder geval niet getest of ze nog booten als de stroom zou uitvallen (of iets dergelijks).

Opscheppen met je uptime was leuk in de tijd dat van Windows 95 (dat na 52 dagen vast liep) maar dat is wel heel lang geleden.

[mike123]

Een stukje uit het artikel van Reddit over uptime.

"And then there are the folks that just want to join the uptime club and set a record. To do that, you have to beat the computer onboard the Voyager 2 spacecraft. Yeah, the one that was the second to enter interstellar space. That computer has been running for 16,735 days (48+ years), and counting.

For terrestrial records, 6,014 days (16 years) seems to be the record for a server, but I've seen plenty of debate over other contenders for the crown. (The small /r/uptimeporn/Reddit community has plenty of examples of extended uptimes.)"

[Verwijderd]

Hardware kan ook gewoon falen over tijd.

Ik vindt een reboot eens in de zoveel gezond zelfs. Flushed alles ook. En de performance is vaak net weer iets beter.

[Roel1966]

Bij het lezen van de kop van het artikel dacht ik van aj dat is dan wel een gevaarlijke bug maar later realiseerde ik mij pas hoeveel jaar 1044 dagen zijn. Grofweg zou dat neerkomen op ongeveer 2 jaar en 8 maanden en tja, dat lijkt mij toch ook voor een server best wel een tamelijke tijd. Kan mij zo voorstellen dat in die tussentijd wel vaker updates zijn waarna een reset nodig is van de server.

Alleen heb ik er even geen idee van hoe lang het duurt eer een server weer opnieuw opgestart is en of dit dan voor problemen kan zorgen.

[SilentDecode]

Alleen heb ik er even geen idee van hoe lang het duurt eer een server weer opnieuw opgestart is en of dit dan voor problemen kan zorgen.

Een boot van een server duurt vaak maar een paar minuten tegenwoordig. Ligt voornamelijk aan hoeveel hardware er aan gestuurd word.

Verder staan servers vaak in HA, waardoor de andere server(s) de taken over kunnen nemen tijdelijk om de server te herstarten voor updates. Vaak gaat dit hele HA proces vrijwel automatisch (mits goed ingesteld).

[Roel1966]

Ja dan zou het eigenlijk niet echt een probleem vormen als dan zo'n server na pak weg 2 jaar en 8 mnd een reset nodig heeft. Tuurlijk, het hoort niet maar het is voor zover ik dan begrijp ook weer niet zo dat zo'n server dan compleet eruit ligt.

[SilentDecode]

Of je werkt gewoon optijd je firmware en software bij, want er komt altijd wel updates uit voor vanalles. Ik zie letterlijk geen reden om niet gewoon optijd, ook op datacenterschaal, spul niet te herstarten...

Als je je updates en firmware goed bijhoudt, heb je vaak maximaal een uptime van 1,5 a 2 maanden. Juist op datacenterschaal kan dit goed geregeld worden, omdat daar de hele zooi in HA draait.

[powerboat]

Tja ... zet standaard bij servers sowieso die energiebesparende maatregelen uit. Bij Intel ook zat (performance) issues mee gehad.

Maar hoe je het wend of keerd het is en blijft mensen werk, zero tolerance is een utopie.

[Zezura]

Waar haal je die bewering van vandaan?

[Frame164]

Het feit dat amd nog altijd geen flinke footprint heeft in datacenters zegt een hoop denk ik. Daar worden beslissingen gemaakt op TCO en niet op emotie/fanboy zaken. En men is erg terughoudend om daar AMD naar binnen te schuiven.

[i-chat]

feit? (bronnen?)
TCO? (nog meer bronnen?)

dat men daar beslissingen maakt die niet gerelateerd zijn aan fanboyism ga ik wel in mee, maar welke belangen er wel spelen? ik gok dat men vooral ook gewoon
A: gebruikt wat bekend is! nieuwe systemen = nieuwe problemen,
B: gebruikt wat het best leverbaar is (intel heeft aanzienlijk meer productie capaciteit)
C: gebruikt wat men heel lang geleden al besloten heeft (niet over één nacht ijs gaan, leveringscontracten etc).

dat zijn allemaal zeer valide en logische redenen om geen AMD te gebruiken, maar zeer zeker geen van allen omdat AMD spul technisch slechter zijn zijn. Dat wil niet zeggen dat er daarvan niet ook één of meerderen zouden kunnen bestaan. maar als je zoveel inside information schijnt te hebben leg ik de bal wat dat betreft ook bij jou. om welke redenen blijft men volgens jou nog meer weg bij AMD. over welke bugs, issues, beperkingen etc hebben we het dan precies.

[RJG-223]

Het feit dat amd nog altijd geen flinke footprint heeft in datacenters zegt een hoop denk ik. Daar worden beslissingen gemaakt op TCO en niet op emotie/fanboy zaken

En in TCO zit véél meer dan enkel de aanschafprijs, de stabiliteit en de energiezuinigheid. Als dat zo was, dan scoorde AMD al veel hoger. Er zit bijvoorbeeld een stukje risicoinschatting in over de toekomst: als we nu AMD kopen, kunnen we dan over twee jaar nog steeds goede AMD processors kopen, of moeten we dan weer terug naar Intel? Of: als we nu een paar AMD machines kopen, dan nemen initiëel de kosten toe, omdat we een ander platform erbij hebben, en omdat we wellicht minder korting krijgen bij onze Intel-leverancier. Is dat wel de moeite waard ? Of: als we AMD kopen, dan moeten we onze voor Intel geoptimaliseerde software ook gaan optimaliseren voor AMD. Zullen die kosten wel de moeite waard zijn ?

Als jij verstand had van de criteria waarop bedrijven / datacentra beslissingen nemen, zou je dat weten.

[Guru Evi]

Hangt ervan af wat je doet natuurlijk. Voor priemgetallen te rekenen is AMD sneller, voor bedrijfssoftware of met matrixen te rekenen is Intel sneller.

Daarnaast is er inderdaad het probleem van beschikbaarheid. Een Intel systeem kan in 2-3 dagen samengesteld worden en opgestuurd omdat Intel directe capaciteit heeft om duizenden Xeons te leveren. Bij AMD moet een bedrijf zoals Dell al meer dan een jaar voor productie aangeven hoeveel ze gaan kopen en dan nog kan het weken duren alvorens ze een chip krijgen van de fabrikant. Dit heeft als gevolg dat je bij AMD redelijk vast zit aan MSRP terwijl Intel kan stunten met 25-50% korting voor grote klanten.

[Argantonis]

Vreemde opmerking, zeker na Intel's Meltdown en Spectre.

[SuperDre]

Maar daarbij hoef je de server niet te herstarten EN is het probleem tegen te gaan door andere security.

[Argantonis]

Alleen maar deels tegen te gaan, ten koste van performance. Bovendien zijn securitylekken wel wat erger dan eens in de 3 jaar een restart moeten doen. Niemand in de industrie maalt nog om restarts tegenwoordig, containers zijn verplaatsbaar.

[Janspook]

Deze vergeten? nieuws: Intel verhelpt Atom C2000-probleem met nieuwe stepping

Voel een CPU ook zomaar uit.

[Klauwhamer]

Niet om het één of ander maar het gros van alle kernel patches met serieuze performance hits tot gevolg op mijn hypervisors bestaat uit doekjes voor het bloeden van Intel-vulnerabilities.

[Stetsed]

Ik denk dat dit niet een eerlijk antwoord is op deze post. Je moet realiseren dat dit maar de 2de generatie van server CPU’s was die AMD had gemaakt met nieuwe tech. 7001 series kwam hiervoor en was een heel nieuw architectuur.

AMD maakt gigantische stappen maar natuurlijk met nieuwe architecturen komen nieuwe problemen. En we hebben sinds dien all 7003(Milan) en 7004(Genoa) servers die zijn uitgekomen waar zij dus blijkbaar meer focus op leggen.

Is het k*t voor mensen die deze server CPU’s hebben zeker, en dat ze ook zeggen dat ze geen fix planned hebben is ook niet goed. Maar zeggen dat hierdoor “AMD” in zijn geheel slecht is is bullshit.

[mdcoo]

Wij draaien een groot vSphere cluster met deze generatie, en ze performen prima. Beter dan de vergelijkbare Intel Xeon Gold variant die we als vergelijkingsmateriaal hadden gebruikt. De EPYC processoren zijn uiterst nuttig in Hypervisor wereld.

[youridv1]

enige statistieken? of wilde je gewoon even AMD SLECHT, INTEL GOED! blaten op een publieke plek? lucht het op?

[TheVivaldi]

Het is wel voor de eerste keer, want normaal lees ik op techsites juist veel “Intel slecht, AMD goed”-reacties.

[i-chat]

dat gaat zo in golven,

intel P3 versus amd K6 ... we weten allemaal hoe dat zich verhield,

en toen kwamen we met k7 versus P4....
en later zelfs vs p4-dualcore. toen was intel inderdaad gewoon ruk..
en met de komst van core 2 haalde intel wel wat terug, maar al snel kwam de k8 en moest intel met een core2 quad komen die eigenlijk gewoon lachtwekkend slecht was.

het nadeel van k8, k9 en k10 was dat deze echt verschrikkelijk schaalden, dus toen het
k9 / k10 vs core iX werd ging intel tot aan de zesde gen 6600k vrij goed...

en toen kwam het 10nm debacle, naar de geruchten gaan had intel een prima opvolger klaar had liggen die het in principe ook prima op had kunnen nemen tegen de eerste generatie ryzen's ... feit is wel dat maar intel kreeg zijn productie niet op orde en daardoor kon men dit ontwerp niet gaan maken / testen / uitbrengen voor massa-productie. AMD had ineens een aantal jaren op rij vrij spel en dat is duidelijk te zien .. generatie op generatie zen-cores gaan momenteel vrij goed en intel is eindelijk weer een beetje bij.. dus dit was wel een big win voor de underdog..

maar vroeg of laat zal AMD niet meer verder kunnen met de ZEN architectuur, misschien nog een zen5 core of een zen6 ... maar dan zal de koek wel op zijn, Voor die tijd mogen we eer ook wel vanuit gaan dat intel met iets nieuws komt, ze doen het nu leuk met hun big-little strategie maar eens daar een monster-core ontwerp bij komt kijken zal zen ook zijn relevantie verliezen. en wie dan de kroon in handen krijgt zal alleen de toekomst leren. ik zou het bijzonder knap vinden als het AMD nog eens lukt (zo snel al) om intel een stap voor te blijven.

[youridv1]

dan ben je misschien erg nieuw. Jaren lang is het intel goed geweest.

[TheVivaldi]

Ik ben met mijn 31 jaar, waarvan een groot deel techie, zeker niet nieuw.

[youridv1]

Dan vraag ik me ten zeerste af waar je was tijdens het meeste recente tijdperk van AMD slecht. Was je op vakantie tijdens FX?

[curkey]

Zulke boude uitspraken nodigen wel uit tot vragen om verdere onderbouwing.

[i-chat]

die AMD zooi is natuurlijk (volgens betrouwbare : of is tweakers.net redactie onbetrouwbaar volgens jou), de afgelopen jaren overduidelijk beter, betrouwbaarder, zuiniger en sneller geweest dan intel.

ik snap dat jij dergelijke verhalen misschien niet gelooft, maar maar tot ongeveer anderhalf jaar geleden waren alle intel cpu's in feite zwaar overgeklokte intel core i? 6x00 chips. en het is zeker niet de eerste keer dat intel dit truucje uithaalt Netburst was precies hetzelfde verhaal.

maar nu komt het grappige feit van dit verhaal.. bijna al deze mega verbeteringen op cpu gebied,
de eerste keer dat AMD een x86-64 chip kon maken die zoveel sneller was dan alles wat men daarvoor ooit had gemaakt. met de pentium 4 de eerste keer dat men met echte multi-core cpu's kam op x86, de uitvinding van vt-d en vt-x en hyper-threading, recentelijk apple's M1 cpu's het hele Ryzen avontuur van AMD. al deze sprongen worden doorgaans gemaakt door een klein groepje mensen die letterlijk vandaag bij de een en morgen bij de ander aan de slag zijn.

die AMD troep is vermoedelijk letterlijk door dezelfe perso(o)n(en) bedacht als waar intel een apple nu mee werken.

[Janspook]

nieuws: Intel verhelpt Atom C2000-probleem met nieuwe stepping
Deze vergeten?
Heeft meer impact gehad dan deze cpu..