Microsoft pleit voor ecc-geheugen in clients

Op de WinHEC heeft Microsoft een lans gebroken voor de toepassing van ecc-geheugen in desktops en laptops. Onderzoek zou uitwijzen dat het fout uitlezen van een bit inmiddels bij de tien belangrijkste oorzaken voor vastlopende computers hoort.

Microsoft deed op de conferentie uit de doeken dat 'single bit errors', waarbij een enkel bitje incorrect wordt uitgelezen, steeds vaker in het Online Crash Analysis-onderzoeksprogramma opduiken als veroorzaker van een crash. Halverwege de negentiger jaren pleitte Microsoft al voor het gebruik van ecc in clients, maar toen vond het bedrijf geen gehoor: het aantal crashes dat door geheugenfouten zou worden veroorzaakt, viel in het niet bij het aantal keren dat een Windows-installatie uit eigen beweging op zijn snufferd ging. Nu Microsofts besturingssystemen een stuk stabieler zijn geworden, heeft het volgens het bedrijf zin om de discussie opnieuw te openen. De softwarefabrikant kan echter nog niet hardmaken dat het gebruik van ecc-geheugen zin heeft: de rapportages die crashende Windows-machines naar Redmond sturen, zijn niet volledig genoeg om aan te tonen dat ecc-geheugen een significante daling van het aantal vastlopende computers zou opleveren.

Windows-serversystemen moeten het zelfcorrigerende geheugen verplicht aan boord hebben om WHQL-goedkeuring van de softwaremaker te krijgen. In clientsystemen wordt het dure geheugen echter zelden toegepast: fabrikanten willen de meerprijs van extra paritychips en nieuwe geheugencontrollers vermijden. Daarnaast hadden oudere geheugentypes als sdram en de eerste generatie ddr wel degelijk enige ecc-functionaliteit aan boord, maar daar werd door computerbouwers geen gebruik van gemaakt. Bij de ontwikkeling van ddr2 werd deze functionaliteit dan ook uit economische overwegingen geschrapt. Bovendien, zo wist Microns vice-president Dean Klein te melden, is het aantal omvallende bitjes in de laatste generaties geheugen aanzienlijk afgenomen. Toch wordt ook bij de ontwikkeling van ddr4 weer naar nieuwe maatregelen gekeken om de betrouwbaarheid van het ram te verhogen: als geheugen al minder foutgevoelig is geworden, dan nog is de kans op een fout groter dan vroeger - simpelweg omdat een moderne pc een veelvoud van het geheugen van pc's uit de vorige eeuw aan boord heeft.

Reacties (91)

[roy-t]

DDR2 667mhz non-ecc = €22,- en duurder
DDR2 667mhz ecc = €25,-

linkje: http://www.alternate.nl/h...=I9HE2E&showTechData=true

dus zoveel maakt het tegenwoordig niet meer uit

[PolarBear]

Inderdaad en het kan alleen maar een positief effect hebben.

[Ultraman]

Ja dat klopt.
Kwa snelheid is het gelijk, alleen een extra bitje voor de ECC data.
En mocht er een bitje omvallen dan kan de ECC die corrigeren en dat neemt dan een extra kloktik in beslag tegenover een crash. Wat natuurlijk een aangename ruil is.

[Verwijderd]

En je kan het nu ook al vrijwillig in client-systemen stoppen, toch?

Ik moet eerlijk bekennen dat ik niet meer helemaal op de hoogte ben van alle BIOS-geheugenopties in het DDR2 tijdperk, maar SDR en DDR mobo's konden dacht ik i.h.a. wel met ECC geheugen omgaan, alleen niet met parity geheugen.

Weet iemand of dit bij alle huidige s775/AM2 moederborden kan?

[Vyo]

volgens mij niet, bij AMD moet je dan Socket 940 of Socket F hebben, de serverbordjes dus.

[stewie]

op s775 en 939/AM2 kunnen inderdaad allebei EEC aan, dit heeft niets met het moederbord te maken aangezien de geheugen controller op de CPU zit en dat is ook de reden dat alle 64bit AMD's EEC ondersteuenen omdat alle chips dezelfde geheugen controller hebben.

[Verwijderd]

Ik zat net even de handleiding te bekijken van het op dit moment meest populaire s775 bord (Asus P5B) en daaruit blijkt dat dit bord i.i.g. geen ECC geheugen aankan.

[Will_M]

Een aantal maanden geleden hebben we op het werk een swap actie gehad waarbij alle (+/-) 7000 pc's/laptops vervangen zijn. We zijn toen overgaan van P4/P4m/Centrino's en een aantal Mobile Celerons met 512MB DDR naar Core(2)Duo's met minimaal 1GB DDR2 aanboord.

Ik ben persoonlijk betrokken geweest bij de opbouw van het image wat op deze nieuwe machines geplaatst moest worden (net zoals ik dat ook al was bij de oude machines),en daar is qua opbouw niks aan veranderd. (Uiteraard wél helemaal up to date gebracht, maar dat gebeurd bij die "oude" machines ook doormiddel van een goed ingeregeld patch-management process.)

Sinds die nieuwe machines draaien krijgen we echter wel vaker meldingen van gebruikers die een geheugen leesfout impliceren, vaak aangaande pakketen die virtuele drivers aanmaken.

Één van die "pakketen" is overigens MSTSC.exe van Microsoft zelf. KB899266 geeft de eerste melding goed weer..... daarna komen de leesfouten op geheugen.

[mjtdevries]

Ik vraag me af hoe jij van meldingen kunt vermoeden dat ze "geheugen leesfouten impliceren" terwijl je hardware hebt, die dat helemaal niet kan constateren.

[Luno]

Waarom heeft iedereen het over crashende programma's ?

Dat is nog eigenlijk het minst erge, maar als het bitje omval in het datagedeelte van bv een spreadsheet, crasht er niets, maar staan er wel fouten resultaten.

Afgezien dat ik nog nooit een server heb gekocht zonder ECC, zou ik nog liever hebben dat de server crashte, dan dat ie alles aan het vernaggelen was.

Vroegâh hadden de clients tenminste nog een paritybit, als er een bitje omviel was tenminste een melding. ECC is een stap verder.

Wat mij betreft: servers altijd ECC, en clients op z'n minst parity terug.

[TD-er]

Wat mij betreft: servers altijd ECC, en clients op z'n minst parity terug.

Puur qua kosten zal er niet echt veel verschil zitten in parity of ECC geheugen. De hoeveelheid extra geheugen is namelijk hetzelfde. Tenzij je fabrikanten krijgt, zoals vroeger Topless, die een chipje erop zetten die de parity on-the-fly gaat berekenen.
Het verschil zou dan alleen nog maar zitten in de ECC-controller-chip en productie-aantallen.
Tegenwoordig zou het ook niet zo'n probleem zijn om de ECC afhandeling in de CPU te doen, aangezien daar toch al de geheugencontroller zit. Dan ondervang je gelijk de eventuele fouten die optreden tussen controller (CPU dus) en de modules.
Oftewel gewoon 72 of 144 bits geheugen gebruiken

[Verwijderd]

Je kan niet echt spreken over "de" ECC afhandeling. In een CPU (ook een desktop exemplaar) wordt op een aantal niveau's gebruik gemaakt van ECC (registers, L1 en L2). Maar volgens mij kan je op een AMD mobo (met memcontroller dus op de CPU) ook gewoon gebruik makem van ECC op het RAM.

[silentsnake]

Moet de memory controller dan ook niet overweg kenne met ECC geheugen? Ik bedoel ... in een AM2 systeem waar een Athlon X2 inzit kan je toch niet zomaar ECC geheugen in proppen?

[DarkJack]

o jawel, alle memcontrollers ondersteunen ECC, waar jij het over hebt is registered memory, alleen server CPUs en mobos ondersteunen (en in vele gevallen zelfs eisen) registered memory.

[Laurent]

Als dat het geval zou zijn, zou bij de DDR1 en oude SDR repen ook gebruik moeten zijn gemaakt van de ECC chip, terwijl dit niet gebeurde volgens dit artikel.

ECC gehuegen werkt prima op geheugencontrollers zonder ECC support, maar dan wordt het extra ECC-chipje simpelweg niet benut. Wil je dus gebruik maken van de feature waar het nu om draait, is toch een andere geheugencontroller benodigd.

Zie ook: deze FAQ voor meer uitleg m.b.t. ECC

[Verwijderd]

Als dat het geval zou zijn, zou bij de DDR1 en oude SDR repen ook gebruik moeten zijn gemaakt van de ECC chip, terwijl dit niet gebeurde volgens dit artikel.

Dat is dus niet helemaal waar, in het artikel staat:

"Daarnaast hadden oudere geheugentypes als sdram en de eerste generatie ddr wel degelijk enige ecc-functionaliteit aan boord, maar daar werd door computerbouwers geen gebruik van gemaakt. Bij de ontwikkeling van ddr2 werd deze functionaliteit dan ook uit economische overwegingen geschrapt."

[Snake]

Nope, dat wordt dan ofwel, als de memory controller op de mamaplank zit, een nieuwe mamaplank, of als de memory controller op de CPU zit, een nieuwe CPU

Overigens ben ik het deels eens, en deels oneens.
Als effectief 10% van de crashes komen voor dat soort geheugenfouten, agree, maar het is anders ook een heel gemakkelijke manier om je instabiliteit af te schuiven op iets anders.

[Rukapul]

Iemand een bron over hoevaak ECC errors voorkomen?

In http://www.corsairmemory....roducts/tech/trg-ecc.html hebben ze het over elke 750 uur op een totaal van 256 MB geheugen.

Op zich zou je hiermee een vrij aardig (en bovenal praktisch) experiment kunnen doen: schrijf een vast patroon in het geheugen van een PC (zeg 4 GB) en controleer dat permanent. Gemiddeld zou je dan elke 2 dagen (46.875 uur) ca een foute bit erbij moeten detecteren.

[CAPSLOCK2000]

het programmaatje "memtest86" doet dit voor je. Bootbare images te downloaden van http://www.memtest86.com/.

Sommige Linux distributies leveren het ook mee. Bij Knoppix kun je tijdens het booten er bijvoorbeeld voor kiezen om een memtest te doen.

Het enige nadeel is dat als je het goed wil doen je computer wel een paar dagen moeten laten staan stampen.

[fevenhuis]

http://www.memtest.org/

Memtest+ is een moderne bijgewerkte versie van memtest, wel zo handig voor moderne (en oude) systemen...

[daft_dutch]

Als er willekeurig een bitje omvalt van een programma dan crasht. Waarom zijn het dan altijd de zelfde programma's die crashen

[PolarBear]

Omdat dat misschien niet aan een omgevallen bitje ligt? Of omdat het programma extreem gevoelig is voor omgevallen bitjes?

[Defspace]

Omdat crashes in de meeste gevallen _niet_ worden veroorzaakt door een omvallend bitje maar door slecht geschreven software/drivers etc...

[0rbit]

10% van de programma's die crashen worden volgens Microsoft veroorzaakt door single bit errors. Die overige 9 van de 10 keer is het inderdaad vaak hetzelfde programma. Daar is ECC dus ook niet voor bedoeld.

[Verwijderd]

Nee, dit is 1 van de 10 belangrijkste oorzaken, dat wil niet zeggen dat ze een gelijk aandeel hebben in het crashen.

[Nijn]

Zoals al gezegd, het gaat hier maar om 10% van de crashes. Maar Het ene programma zal er meer last van hebben dan andere. Photoshop doet veel meer met geheugen en heeft er dus veel meer last van dan kladblok.

[Verwijderd]

Nee, die 10% staat nergens. Het is één van de 10 belangrijkste oorzaken. Knullige software op plaats één kan een aandeel van 99,9 % hebben. Omvallende bitjes op plaats twee kan 0,1% procent van de crashes veroorzaken
Ik denk dat Vich hierboven hetzelfde bedoelt.

[-darkstar-]

Volgens mij zijn dit gewoon excuses voor een (te) buggy OS (ieder OS in min of meerdere mate is).

Want voor ik zover weet is dit bij linux niet het geval...

Heb zelf 2 systemen met Windows zijn ze minder stabiel als wanneer ik linux erop beide zet. Maar ja met linux krijg ik geen BSOD's .

Ik denk zelf dat ECC niet nodig is, geheugen is door de jaren beter en beter geworden.

Misschien wil Microsoft na vista zich extra inspannen om ervoor te zorgen dat hardware fabrikanten meer gaan verkopen.

Voor de rest lijkt de onderbouwing meer op natte vingerwerk dan echt bewijs.

[SuperDre]

vreemd, want sinds gebruik van XP heb ik geen BSOD meer gezien op al onze computers, behalve toen er op 1tje een HD kapot was, maar daar lag het dus echt aan de HD, en dan vindt ik een BSOD echt niet erg, maar heb ik em liever zodat ik weet dat er wat aan de hand is..

[Larsie]

Ik denk niet dat het veel zal helpen:

Als ram verkeerd wordt uitgelezen is er naar mijn mening iets kapot.

Ik zie Ecc als een medicijn, maar zoals gewoonlijk: Genezen is beter dan voorkomen

Ik snap ook best dat het in servers wordt gebruikt, het is toch weer extra veiligheid. Net als backup voedingen en/of een ups, of Raid mirroring, in theorie hoort een schijf niet uit te vallen, maar als het dan toch een keer gebeurt.....

Edit:

Ik bedenk me nog een ander nadeel. Als veel fabrikanten Ecc gaan gebruiken zal waarschijnlijk de kwaliteit van het geheugen zelf achteruit gaan.

Ik zie het al voor me tijdens een Quality Check "Ach hij haalt net niet timing X. Maar wat maakt het ook uit dankzij Ecc gaat het toch 9 van de 10 keer goed"

@therat10430:

Dat is dan niet de schuld van het geheugen inderdaad, maar van stroompiekjes en magnetisme hebben andere onderdelen net zo hard last. Een goed afgeschermde kast met een goede voeding lijkt me dus raadzamer

[roy-t]

Maar ecc zit al op de chip zelf, (mobo kan het nogsteeds fout doen) en bitjes kunnen omvallen door stroom piekjes en magnetisme, dat is bijna niet tegen te gaan denk ik.

[Verwijderd]

Dat is dan niet de schuld van het geheugen inderdaad, maar van stroompiekjes en magnetisme hebben andere onderdelen net zo hard last. Een goed afgeschermde kast met een goede voeding lijkt me dus raadzamer

Soft errors in RAM hebben niets te maken met stroompiekjes of magnetisme, maar zijn te wijten aan geladen deeltjes (beta en alfa deeltjes). Alfa/beta stralers zitten inherent als onzuiverheden in sommige materialen die gebruikt worden in chips (bv lood). De rest is te wijten aan kosmische straling en radon dochters.

[Nijn]

Een geheugenchip is idd kapot als het steeds op dezelfde plaats een fout heeft. Maar het omvallen van een bitje is niet zo ongewoon als je denkt.

Of dat nou door de omgeving of door de chip komt is een zinloze discussie. Het gebeurt, en ECC is een goede manier om het op te lossen.

[Verwijderd]

Het achterliggende mechanisme is wel belangrijk om in het achterhoofd te houden. De tracks van geladen deeltjes in Si blijven gelijk ongeacht of het nu een 22 nm of 180 nm proces is. Hoe kleiner het proces, hoe groter de kans dat meerdere transistoren geshort worden in het pad, en er dus meerdere soft errors tegelijkertijd optreden. Dan ben je niets meer met ECC in de huidige vorm.

[mxcreep]

Wat ik veel vaker tegenkom als een probleem in pc's wanneer er vaker vastlopers zijn is de voeding van het beestje. De meest onverklaarbare problemen treden op wanneer een voeding niet echt in orde meer is of gewoon een el cheapo voeding die ook nog eens te veel belast wordt.
Zaken als geheugen maar bijvoorbeeld ook raid controllers kunnen behoorlijk flauw gaan doen met een niet goed meer functionerende voeding. Voor de gemiddelde thuis gebruiker is het helaas echter lastig te achterhalen of ie wel of niet ok is.

[Zware Unit]

Het is toch niet voor niets dat Xeon's ECC gebruiken. Toch is het geheel afhankelijk van de additionele kosten die je voor ECC betaald. Veel consumenten hebben dit er echt niet voor over.

Gelukkig zijn de geheugen prijzen gedaald en is het geheugen voor mijn MacPro betaalbaar geworden.

[Gustaaf437]

Toen Apple voor het eerst ECC geheugen introduceerde in de Xserve G5, was het geheugen inderdaad nog idioot duur. De prijzen zijn nu al zeker gehalveerd, maar ik denk dat er nog wel 50 - 75% vanaf moet, voordat het ook voor de consument betaalbaar is.

Dat Apple en ook andere al een tijdje ECC geheugen toepassen is natuurlijk een goed gegeven. Vanaf eind volgend jaar zullen we steeds meer ECC machines gaan zien en het zal in 2010 wel mainstream zijn. Kan best snel gaan dus, moeten de prijzen wel eerst even een inhaalslag maken om (bijna) gelijk te komen aan non-ECC geheugen.

[Verwijderd]

Als je het puur produktie technisch bekijkt zal unbuffered ecc geheugen 12,5 % duurder zijn. Er zijn namelijk x*9 ipv x*8 chips nodig. Aanzien de productie kosten van het printje het zelfde zijn zal het prijsverschil waarschijnlijk minder dan 12,5 % zijn.

Meegenomen dat unbuffered ecc geheugen standaard geheugen wordt.

[Luno]

Je verwart parity met ECC.

Bij de oorspronkelijk PC's was er per 8 bits 1 parity bit. Voor ECC heb je meer nodig. Als je ECC per 8 bits zou doen dan heb je 4 extra bits nodig. Daar wordt het meestal per 32 bits gedaan (6 bits extra).

Die 12.5% slaat dus op parity. Voor ECC zit je meer in de 20% range (ECC per 32 bits). Ga je op nog grotere lengtes het implementeren dan wordt het minder, maar maak je het te groot dan wordt de detectie kans bij omvallen van meerdere bitjes weer minder.

[Verwijderd]

@Luno
Je verwart parity met ECC.

Nee, dat doe ik niet. Volgens mij zijn de huidige ECC chips nog met 1 bit per 8 bit's extra. Dus 4 extra per 32.

Zie:
http://www.pcguide.com/ref/ram/errParity-c.html

<quote>
Warning: Most ECC and parity modules have the same designation and bit widths, which means that a 4x72-60 DIMM could be either an ECC module or a parity module, depending on how it has been manufactured.
</quote>

http://www.pcguide.com/ref/ram/packParity-c.html

(Ik heb een paar severs met ECC, deze hebben x*9 chips ipv x*8 chips)

Deze link toegevoegd.
Zie deze link ook:
http://www.directron.com/kvr400d2s4r31g.html

Hoet praten ze over ECC met 72 bits ipv 64 bits. Dus 8*9 ipv 8*8.

Dit is volgens mij nog steeds het geval bij ECC. Mogelijk dat High-End servers meer bits gebruiken.

[Luno]

Sorry, maar met 1 extra (per x) bit kun je alleen een fout detecteren, niet corrigeren.

Voor correctie je echt meer bits nodig.

Voor 8 bits heb je 4 bits extra nodig, voor 16 bits woorden 5 bits, voor 32 bits woorden 6 bits, en voor 64 bits woorden 7 bits. Dan kun je 1 kapot bit detecteren.
Ga je voor 64 bits met 8 bits ECC dan kun je ook 2 kapotte bits detecteren. Nb. dit lijkt op een byte van 8 bits + 1, maar is wezenlijk anders.

Voor de ECC zijn we speciale polynoom functies om trefkans zo groot mogelijk te maken. Dan kun je met 64 bits 7 bits niet alleen 1 kapotte bit (met zekerheid), maar ook 2 kapotte bits met minder zekerheid detecteren en corrigeren.

[dion_b]

Die verhoudingen die je noemt gaan ervan uit dat de kosten van de chips de enige kosten zijn van een DIMM.

Dat is natuurlijk niet zo. De PCB kost geld, de assemblage kost geld, de research kost geld. het testen kost geld, de marketing kost geld etc. etc. etc. - allemaal factoren die vrijwel identiek zijn voor ECC vs non-ECC. Dus het intrinsieke prijsverschil is significant lager dan 12.5%

[mieJas]

De PCB's blijven hetzelfde. Je moet maar eens kijken op een RAM-latje. Je zal zien dat er plaats (en koper) aanwezig is voor een extra chip.

In de midden:
http://img.alibaba.com/ph...ory__Module__DDR__RAM.jpg

[TD-er]

Dus het intrinsieke prijsverschil is significant lager dan 12.5%

Ik weet niet of de chips vervangen worden, zodra er een defect op een module geconstateerd is. Indien niet, dan zal procentueel gezien wel meer uitval zijn en indien wel, dan zal vaker een module opnieuw gesoldeerd moeten worden voordat deze de fabriek verlaat. (meer chips, dus meer kans op een defect)
Dus of de productiekosten significant lager zullen liggen dan die 12,5% durf ik niet zozeer te zeggen.

[Verwijderd]

@Luno

Ga je voor 64 bits met 8 bits ECC dan kun je ook 2 kapotte bits detecteren.

2 detecteren en 1 corrigeren, toch?

Dit is ook precies het geval. Een DIMM is 64 bits breed. Volgens mij heb ik niet 8+1 bit gezegd. Ik vermelde x*8 en x*9 waar x=8 voor een huidige DDR en DDR2 DIMM en voorheen SDRAM DIMM (x*8 = 64 voor non-ECC en x*9=72 voor ECC).

Nog over de x in een chips zitten meestal 4 of 8 datalijnen. Vandaar dat er vaak 8/9 of 16/18 chips op een DIMM zitten (no-ecc/ecc aantal).

Volgens mij is ook de belangrijkste taak van ECC geheugen het detecteren van een defect geheugen bij een draaiend systeem, wat een non-ECC niet kan. Dan het corrigeren van een error, dit is mooi meegenomen, om nog te werken tot het geheugen vervangen wordt.

Extra info toegevoegd.

[Verwijderd]

Sorry, maar met 1 extra (per x) bit kun je alleen een fout detecteren, niet corrigeren.

Kan jij dan uitleggen wat het verschil is tussen detecteren en corrigeren? Als je een fout detecteert kan je de bit/byte/word/etc toch opnieuw opvragen?

[newinca]

Het gaat om fouten die optraden in het geheugen zelf, niet bij het transfereren: er valt dus niets meer opnieuw op te vragen, want de data zelf is verkeerd.

Bij detecteren bemerk je dat er een probleem is (en laat je de computer, bijvoorbeeld, stoppen ipv laten verder doen met verkeerde data.) Bij corrigeren heb je genoeg correctiebits om de data terug te herstellen in zijn oorspronkelijke staat.

[Vastloper]

Het detecteren van de fout gebeurt 100% op de dimm module en heeft niks met software of het stoppen hiervan te maken. De extra chips die nodig zijn bij ecc dimm's is wel degelijk om ook te corigeren. Nog steeds niks met software te maken. Je kunt uiteraard ook alls softwarematig doen inclusief het opslaan in een ecc formaat en dit softwarematig afvangen, alleen aangezien het geheugen toch al vaak de bottleneck is qua performance en zo'n software check een enorme overhead zou opleveren op je algemene performance wil je dit echt wel 100% in hardware. Hierbij kun je in hardware nog onderscheid gaan maken in forward error correction (fec) dit hoeft echt niet veel extra bits te kosten met behulp van bijvoorbeeld een 2d parity check. Maar dit leren de meeste mensen niet bij de standaard vakken over deze onderwerpen. Je kunt alles zo gek maken als je wilt en alles 4voudig opslaan, maar als je naar de statistieken kijkt van geheugen dan is het zeeeeeeeeeeer onwaarschijnlijk dat je uberhaupt meer dan 1 bit fout hebt per blok geheugen en is het direct kunnen corrigeren van meer dan 1 bit al overbodig. En aangezien het moeten corigeren van 1 bit al zo weinig voorkomt dat de performance impact hiervan verwaarloosbaar is, is fec al praktisch zinloos en kun je beter opnieuw proberen als het een leesfout was en evt een fout doorgeven aan de processor/OS als het al een schrijffout was, zodat dit adequaat kan worden afgehandelt.

[MaxxBass]

Xeon zijn dan ook server chips, dit gaat over client pc's... niet over heavy workstations en desktopjes..

[Phoenix_X]

Dat lijkt me duidelijk; het is een samenzwering van RAM fabrikanten tegen bepaalde software!

[Dark Angel 58]

Goed plan..... Microsoft is goed op weg naar 64bit Operating System! Dan wordt Windows nog steeds stabieler dan nu.
Daar heb ik helemaal geen bezwaar mee, want ik ben voorstander van 64bit OS!
Windows en processors hadden allang moeten geevolueerd 64bit! Jammer dat er zo veel luie programmeurs zijn, die geen zin hebben om 64bit drivers en of 64bit programma's willen ontwikkelen!

[Verwijderd]

Volgens mij mis ik hier iets, wat heeft dit met 64 bit te maken. Verder zorgt een 64 bit OS niet direct voor een verhoogde stabiliteit. Ook het grootste deel van de markt maakt nog steeds gebruik van 32bit Operating Systems dus het is niet echt heel rendabel om 64 bit drivers te maken, heeft niks met luiheid te maken.

oh ja, er is al een 64 bit versie van XP, Vista en server 2003, verder zijn er genoeg 64bit Linux distro's.

En over ECC, 10% van de crashes is voor mij een te klein aandeel om er extra geld aan uit te geven.

[humbug]

Jammer dat er zo veel luie programmeurs zijn, die geen zin hebben om 64bit drivers en of 64bit programma's willen ontwikkelen!

Dat heeft weinig met luiheid te maken. Als een 32bits programma goed werkt en geen enorme hoeveelheden geheugen nodig heeft, waarom dan duizenden euro's investeren? Kun je beter aan andere software werken waar je wél extra functionaliteit nodig hebt.

Bij drivers ligt dat iets anders aangezien hardware mogelijk meer verkocht zou worden met 64bits windows drivers, maar dan zit je nog met de "oude" hardware. Er is geen reden om voor 3 jaar oude hardware nog nieuwe drivers te gaan maken.

Daarnaast is het gebruik van 64bits windows nog nihil. Bepaalde serversoftware (oa exchange 2007) profiteert van 64bit windows en je ziet dan ook dat hardware voor die toepassingen ook met 64bit drivers wordt uitgerust. Maar consumenten hardware? Voor die 2 tweakers die een 64bits versie van windows draaien? Gewoon de tijd en het geld niet waard.

[houseparty]

Microsoft is goed op weg naar 64bit Operating System! Dan wordt Windows nog steeds stabieler dan nu.

Als ik 't artikel goed heb gelezen, dan lees ik tussen de regels door dat MS juist verbeterde geheugen stabiliteit gewenst acht wanneer we werkelijk het 64-bit tijdperk ingaan. ECC is slechts een middel om die stabiliteit te verbeteren.

Een 64-bit OS heeft namelijk als hoofd voordeel dat er méér geheugen aangesproken kan worden.

Als het echt zo is dat omvallende bitjes nu al in de top-10 veroorzakers van crashes staan, dan zal het aandeel bij verdere geheugen toename alleen maar toenemen.
Mits er iets significants wordt ondernomen om de stabiliteit van werkgeheugen te verbeteren.