Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Core » Hardware » Microsoft pleit voor ecc-geheugen in clients

Microsoft pleit voor ecc-geheugen in clients

Door René Wichers, zaterdag 19 mei 2007 18:10
Bron: EE Times, views: 22.641

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.

Kingston fully buffered ecc-dimm'etje 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.

Volgende 20:10 Blizzard kondigt StarCraft 2 aan
Vorige 15:02 Microsoft steunt odf-formaat als Ansi-standaard
Advertentie

Categorieën

Gerelateerde content

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 91 reacties zichtbaar910 Off-topic / Irrelevant: 88 reacties zichtbaar88+1 On-topic: 74 reacties zichtbaar74+2 Informatief: 5 reacties zichtbaar5+3 Spotlight: 0 reacties zichtbaar0
«  1  2  3  4  »

Door Zware Unit, zaterdag 19 mei 2007 18:16

Score: 1
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.

Door Gustaaf437, zaterdag 19 mei 2007 19:02

Score: 1
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.

Door worldcitizen, zaterdag 19 mei 2007 19:23

Score: 1
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.

Door dion_b, zaterdag 19 mei 2007 19:49

Score: 0
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%

Door mieJas, zaterdag 19 mei 2007 19:56

Score: 1
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

Door TD-er, zaterdag 19 mei 2007 19:57

Score: 1
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.

Door Luno, zaterdag 19 mei 2007 19:58

Score: 1
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.

Door worldcitizen, zaterdag 19 mei 2007 21:28

Score: 1
@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.

Door Luno, zaterdag 19 mei 2007 22:36

Score: 1
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.

Door worldcitizen, zondag 20 mei 2007 00:02

Score: 1
@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.

Door grizzlybeer, zondag 20 mei 2007 01:03

Score: 1
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?

Door newinca, zondag 20 mei 2007 05:08

Score: 1
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.

Door Vastloper, maandag 21 mei 2007 10:34

Score: 1
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.

Door MaxxBass, zondag 20 mei 2007 00:57

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

Door roy-t, zaterdag 19 mei 2007 18:16

Score: 2
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 :)

Door PolarBear, zaterdag 19 mei 2007 18:21

Score: 0
Inderdaad en het kan alleen maar een positief effect hebben.

Door Ultraman, zaterdag 19 mei 2007 18:49

Score: 1
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.

Door grizzlybeer, zondag 20 mei 2007 01:06

Score: 1
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?

Door Vyo, zondag 20 mei 2007 01:44

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

Door stewie, zondag 20 mei 2007 03:55

Score: 1
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.

Door grizzlybeer, zondag 20 mei 2007 12:18

Score: 1
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.

Door daft_dutch, zaterdag 19 mei 2007 18:16

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

Door PolarBear, zaterdag 19 mei 2007 18:20

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

Door Defspace, zaterdag 19 mei 2007 18:21

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

Door 0rbit, zaterdag 19 mei 2007 18:21

Score: 1
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.

Door Vich, zaterdag 19 mei 2007 19:41

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

Door Nijn, zaterdag 19 mei 2007 19:20

Score: 1
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.

Door hugob123, zondag 20 mei 2007 17:25

Score: 1
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.

Door -darkstar-, zondag 20 mei 2007 02:30

Score: 0
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.

Door SuperDre, zondag 20 mei 2007 20:01

Score: 1
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..

Door Phoenix_X, zaterdag 19 mei 2007 18:19

Score: 1
Dat lijkt me duidelijk; het is een samenzwering van RAM fabrikanten tegen bepaalde software! :Y)

Door jealma, zaterdag 19 mei 2007 18:20

Score: 0
Hele flauwe en lamme streek van MS om omvallende geheugenbitjes de schuld te geven van het random crashen van systemen. Laat ze hun OS'en eens beter debuggen |:(

Door EvilWhiteDragon, zaterdag 19 mei 2007 18:28

Score: 1
Ahja, natuurlijk, jij weet er kennelijk meer van?
Maargoed, ik vindt 10% van de crashes door omvallende bitjes best veel, en het lijkt me dan wel reeel om te kijken naar ecc eigenlijk. dat de overige 90% nog aan driver/software fouten ligt, hoeft neit direct microsofts fout te zijn. Er zijn namelijk nogal veel programma's en drivers niet door MS geschreven.

Door Neko Koneko, zaterdag 19 mei 2007 18:42

Score: 1
Waar lees jij dat MS dit als enige schuldige aanwijst voor crashende computers? Het is gewoon een mogelijke oplossing voor een gedeelte van het probleem.

Maar goed, jij lijkt me dusdanig anti-MS dat je daar waarschijnlijk toch niks van wilt geloven, want MS is evil en doet nooit wat goed, dus waarom luisteren naar iets dat zij zeggen?

Door GH45T, zaterdag 19 mei 2007 18:51

Score: 0
Als Microsoft al de schuld richting het geheugen schuift, waarom dan niet meegaan in het voorstel, ECC geheugen is tegenwoordig nauwelijks duurder meer dan conventioneel geheugen, de chipsets moeten ook wel aan te passen zijn etc.

Als we dan ECC in de desktops hebben zitten, kan Microsoft het geheugen ook niet meer de schuld geven.

Als ik jouw vraag om spullen te kopen bij de fietsenzaak om een band te plakken, het plakken van de band lukt me niet, ik geef aan dat de spullen niet goed zijn en ik vraag je vervolgens specifiek om doosje x met plakspullen te kopen, dan kan ik je vervolgens toch niet meer de schuld gaan geven dat je rommel hebt meegenomen?

Door Larsie, zaterdag 19 mei 2007 18:21

Score: 1
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" :r

@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 ;)

Door roy-t, zaterdag 19 mei 2007 18:25

Score: 1
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.

Door Father_Ted599, zaterdag 19 mei 2007 19:17

Score: 1
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.

Door Nijn, zaterdag 19 mei 2007 19:23

Score: 1
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.

Door Father_Ted599, zaterdag 19 mei 2007 21:13

Score: 1
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.

Door mxcreep, zaterdag 19 mei 2007 21:12

Score: 1
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.

Door silentsnake, zaterdag 19 mei 2007 18:26

Score: 1
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?

Door Snake, zaterdag 19 mei 2007 18:38

Score: 1
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.

Door DarkJack, zaterdag 19 mei 2007 18:40

Score: 2
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.

Door Laurent, zaterdag 19 mei 2007 19:48

Score: 1
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 :)

Door grizzlybeer, zondag 20 mei 2007 01:10

Score: 1
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."

Door Nijn, zaterdag 19 mei 2007 19:25

Score: 1
Niemand verplicht jouw om Aero te gebruiken. MS is een commercieel bedrijf dat luisterd naar de wensen van de meerderheid van de klanten. Daaruit blijkt dat de klanten eyecandy willen en niet al te veel willen betalen. Dus het hele systeem ervoor omgooien is niet te doen, maar de eyecandy moet er wel in. Dan krijg je dit.

Daarnaast, wat heeft dit te maken met ECC geheugen? :?

Door Tijger, zondag 20 mei 2007 08:25

Score: 1
Yep en Beryl valt bijkans iedere 5 minuten om en is nauwelijks Beta te noemen.

Oh enne, Aero draait prima op een 6200 Turbocache kaartje, die is namelijk DX9 compatible.

Door SRI, zaterdag 19 mei 2007 18:50

Score: 0
Nou van mij hoeft het niet hoor,.. draai gewoon windows xp compleet up to date en crashed zelden tot bijna nooit.... alleen bij een bepaald spel telkens... naja das dan dus een duidelijke oorzaak,.. me computer crashed denk nog niet eens tien keer per jaar dus om nou extra geld te betalen voor zo weinig... nee nutteloos!

Moeten we straaks ook van microsoft verplicht een dual core hebben die dan telkens hetzelfde berekenen en zo elkaar controleren op fouten? En dan gelijk nog een sli/crossfire erbij... ga zo maar door.... uiteindelijk crashed het toch wel ergens alleen de vraag is waar is de verhouding tussen minder crashen/geld,.. denk dat de normale burger nu al namelijk op het optimum daarvoor zit.

Door Nijn, zaterdag 19 mei 2007 19:29

Score: 1
Microsoft verplicht niemand iets. Je bent nu toch ook niet verplicht een AMD of Intel te nemen? (jah, risc werkt wat minder). Microsoft plijt voor ECC geheugen. Vind ik een goeie zaak. Maar daarmee verplichten ze toch niets...

Ze zouden wel gek zijn. Als zij alleen ECC geheugen accepteren sluiten ze een deel van de markt uit.

En nee, op server systemen verplichten ze het ook niet. Wat MS wel doet is servers die bedrijven op de markt brengen desgevraagd te keuren op goede werking met MS server software. Daarbij stellen ze ECC geheugen verplicht, maar dat is niets vreemd in de server wereld.

Door Dark Angel 58, zaterdag 19 mei 2007 18:57

Score: 0
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! :(

Door terra86, zaterdag 19 mei 2007 19:15

Score: 1
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.

Door humbug, zaterdag 19 mei 2007 19:22

Score: 1
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.

Door houseparty, zaterdag 19 mei 2007 20:29

Score: 1
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.
«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

Volgende 20:10 Blizzard kondigt StarCraft 2 aan
Vorige 15:02 Microsoft steunt odf-formaat als Ansi-standaard
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011