Hoe pariteit en ECC werken

Dean Kent van Real World Technologies voegt weer eens een artikel toe aan de steeds langere lijst van hoe ... werken-posts. Dit keer gaat het om ECC en pariteit. Iedere overclocker komt een keertje voor de keuze van gewoon of ECC-geheugen, wat een grotere stabiliteit kan betekenen. Er wordt uitgelegd wat het duurdere geheugen kan, waarom het duurder is en wat voor zin het heeft. Hier een stukje over de werking van parity memory:

Parity checking is a rather simple method of detecting memory errors, without any correction capabilities. Basically every byte has a 'parity' bit associated with it, for a total of nine (9) bits per byte (eight data bits plus one parity bit). The parity bit is set at write time, and then calculated and compared at read time to determine if any of the bits have changed since the data was stored. This type of checking is limited to detection of single bit errors. If two bits have been altered, the parity check will 'pass', and the error is allowed to possibly corrupt the data.

Parity checking can be implemented either as '0' parity or '1' parity. When the byte is stored, the number of zeros (or ones, if '1' parity) is added up. The result is stored in the parity bit - '1' if odd, '0' if even. When that byte is read from memory, the bits are again counted and the result compared against what was stored in the parity bit. A match means that the data was not changed from when it was stored (or two bits were altered so the result is the same).[break]En een stukje over ECC:[/break]An even better error checking feature is ECC (Error Correction Checking), which includes not only single bit error detection, but also two, three and four bit detection (depending upon the implementation). In addition, ECC can actually correct single bit errors, so the application can continue as if no problem ever occured. ECC can be implemented either on the module (ECC-on-SIMM, or EOS) or in the chipset, however EOS modules are very rare indeed.

ECC is implemented by a 'hashing' algorithm that works on eight (8) bytes (64 bits) at a time, and places the result into an 8-bit ECC 'word'. At read time, the eight bytes being read are again 'hashed' and the results compared to the stored ECC word, similar to how the parity checking is performed. The main difference is that in parity checking, each parity bit is associated with a single byte while the ECC word is associated with the entire eight bytes. This means that the bit values for ECC will very likely not be the same as the individual parity bits would be for the same eight byte data value, therefore ECC modules cannot be used in parity mode (however, parity modules can be used in ECC mode, as described a bit later). Note that this description for ECC is based upon a memory bus width of 64 bits. If one were to implement ECC on a 486 (32-bit width), it would require seven (7) bits for the ECC word.

Reacties (1)

[MLS]

Had ik ook nog in mijn proxy:

----
2 reakties onder je huidige niveau (0)Niveau 1: 2 postingsNiveau 0: 15 postingsNiveau -1: 17 postingsNiveau -2: 17 postings

Reaktie gepost door Heretic - Woensdag 14 Juni 2000 - 17:56 (Score: 0 )
Ik heb ook liever ECC geheugen, maar het is veel te duur
Het is tenslotte De tweakerspagina: met zo min mogelijk geld een zo bruut mogelijk systeem in elkaar knutselen en dan liever meer geheugen dan ECC


Reaktie gepost door heraut - Woensdag 14 Juni 2000 - 18:00 (Score: 0 )
ik geef liever wat minder geld uit per MB, liever meer MB's dat geeft een beter resultaat in termen van prijs/prestatie...

Heraut (die ook beheerder is van ict.pagina.nl)


Reaktie gepost door XElDiablo - Woensdag 14 Juni 2000 - 18:17 (Score: 1 - Interessant )
ik heb hier nog een ander duur ideetje:

men wille x hoeveelheid geheuge

men hale 3x hoeveelheid geheuge

men zorg voor speciaal mobo

dit mobo doet volgende :
Het slaat de betreffende data 3 keer op (in 3 verschillende geheugen modules), op het moment dat de betreffende data opgevraagd word vraag men dit 3 keer op, en vergelijkt deze, voordat de data verder verwerkt wordt, met elkaar, als er een van de data's een afwijking vertoont dan wordt de code gebruikt die de 2 data's die niet afwijken angeven...., als alle drie de data's niet overeenkomen wordt de betreffende data opnieuw ingelezen (vanaf bijv de HD of een eventuelle vierde "check" memory module...)

Moet je maar eens nagaan hoeveel dit de kans op errors verkleint , die is dan vrijwel niet meer aanwezig


Reaktie gepost door elefino (Moderator) - Woensdag 14 Juni 2000 - 18:33 (Score: 0 )
XElDiablo:
Das natuurlijk een erg leuk plan van je, maar idd veeeeel te duur. En op zich is bijv. die pariteit controle al een behoorlijk betroubaar systeem. Zeker als je ipv "horizontale pariteit" zoals hier omschreven "verticale pariteit" gebruikt. Daarbij zet je een aantal bytes onder elkaar en zet je daar onder een pariteits BYTE ipv achter iedere byte een pariteits BIT.
Ik zal (en kan) het zo snel ff niet voorrekenen hier. Maar met die methode sluit je nog meer fouten uit omdat fouten meestal uit een reeks "omgevallen bits" bestaan. ipv 1.


Reaktie gepost door _mitch_ - Woensdag 14 Juni 2000 - 18:35 (Score: 0 )
ECC geheugen is langzamer dan gewoon geheugen juist omdat het errors checkt...
(so i read)

stabieler? ja, sneller? nee

En aangezien weinig mensen echt last hebben van onstabiel geheugen...


Reaktie gepost door TD-er (Moderator) - Woensdag 14 Juni 2000 - 18:37 (Score: 0 )
XElDiablo
't is dan beter om de Error-correcting-code niet dezelfde te laten zijn, als de data die wordt opgeslagen, omdat er dan via allerlei leuke truukjes de oorspronkelijke data weer hersteld kan worden.
't probleem waar je met jou oplossing tegenaan loopt, is dat je niet weet of er nu 2x een fout is opgetreden of een keer.
dus je kunt niet zondermeer de regel toepassen "De waarde die 2x of meer voorkomt is de juiste"
en als 't al zo erg is dat je 3x de prijs voor dezelfde hoeveelheid geheugen wilt betalen, dan kun je beter investeren in betere afscherming


Reaktie gepost door XElDiablo - Woensdag 14 Juni 2000 - 18:42 (Score: 0 )
Ja da's logisch, maar ik ging bij mijn redenering ook niet aan omgevallen bits, wat in de praktijk vaak voorkomt...

Verder kan je met pariteit wel controlleren maar niet repareren, en bij ECC dit slechts tot een bit..., als er dan nog iets fout gaat moet de data opnieuw opgezocht worden vanuit de orginele bron, terwijl je bij bovenstaande haast altijd een directe reparatie kan toepassen...

Dit alles weegt echter waarschijnlijk niet op tegen de kosten... alhoewel het mischien nog bestwel zou kunnen concureren tegen rambus omdat dit soort ram natuurlijk redelijk hoog geclocked zou kunnen worden...


Reaktie gepost door mrT - Woensdag 14 Juni 2000 - 18:43 (Score: 0 )
oke duidelijk, het is gewoon wiskunde maaruh...hoe vaak komen fouten in de praktijk voor en waarvan zijn ze afhankelijk?


Reaktie gepost door XElDiablo - Woensdag 14 Juni 2000 - 18:46 (Score: 0 )
vorige post was dus als reactie op de reactie van Elefino

en even als reactie op de post van TD-er

:dat er ook kans is dat er 2 verkeerd zijn en dat doorgelaten wordt is vrij klein, want als er iets verkeerd is is de kans redelijk klein dat de 2 corrupte data's ook van elkaar verschillen...


Reaktie gepost door XElDiablo - Woensdag 14 Juni 2000 - 18:47 (Score: 0 - Overbodig )
hé verdorie, in de vorige post moest klein GROOT zijn...


Reaktie gepost door Coen Rijkaart - Woensdag 14 Juni 2000 - 18:59 (Score: 0 - Interessant )
Hmm quote uit artikel
"Since the soft error rate for today's A-grade chips is about once every ten years (or better), it seems to makes sense that non-parity is the norm."

De kans dat er iets foutgaat is dus 1x in de tien jaar.

Dus een thuisgebruiker zou wel gek zijn om op zijn windows bak (die veel vaken dan eens per 10 jaar crashed vanwege andere problemen ) vol te proppen met ECC memory.

Kan je beter het prijs verschil tussen ECC ennon ECC gebruiken om ipv PC 133 CAS 3 CAS2, of zelfs PC150 memory te kopen.
[Reaktie gewijzigd door Coen Rijkaart]


Reaktie gepost door Jrz - Woensdag 14 Juni 2000 - 19:08 (Score: 0 )
XElDiablo
neem dan een raid5 achtig iets
je neemt 3 modules
2xdata, 1xcheck
als de check niet goed is vervang je effe je module en dan recover je je data
hehehe


Reaktie gepost door XElDiablo - Woensdag 14 Juni 2000 - 19:52 (Score: 0 )
reactie op de reactie van Jrz

Ja het is wel zoiets (alhouwel ik er niet aan dacht toen ik dat poste ) , en zoals iedereen weet zijn raid arays waarbij gemirrord wordt ook aan de dure kant..., bij harde schijven is het echter wel logisch, want die maken in verhouding met geheugen VEEEl vaker fouten, zaker als het top performance schijven zijn die de hele dag aan staan..., en als er iets fout gaat is de kans meteen ook veel groter dat het compleet fout gaat...

* XElDiablo is voor het wegwerken van alle bewegende delen uit PC's, met uitzondering op ventilatoren en waterpompen


Reaktie gepost door guaka - Woensdag 14 Juni 2000 - 20:30 (Score: 0 )
Je zou ook echt goede errorcorrecting codes kunnen toepassen, zoals bijvoorbeeld bij CD'tjes gebeurt. Als daar een kras in zit doet ie het vaak nog gewoon... Hij verdeelt de data dan ook over grote vlakken, zodat een kras niet betekent dat een hele rij uitgeveegd is, maar dat er een aantal bitjes, verspreid over (qua data) ver van elkaar liggende words. Audio is ook minder gevoelig dan data, daarom past er relatief meer muziek (78 minuten of zo) dan data (74 minuten) op een standaard CD.

XElDiablo, met 1,5 keer de hoeveelheid geheugen kun je al een super goede errorcorrecting code fabriceren, die ook nog heel erg snel (lineair) te implementeren is...
Voor mensen die nog meer willen weten kan ik mijn dictaat codetheorie er eens op naslaan over wat referenties


Reaktie gepost door XElDiablo - Woensdag 14 Juni 2000 - 21:31 (Score: 0 )
Reactie op de post van Guaka

Ik had ook wel zo'n idee dat dat best wel mogelijk is, ik heb hier echter geen dictaat codetheorie bij de hand (ik ben nu ook nog maar een simpele vwo5-er van 17 jaar die een hoop van zijn tijd op sites zoals tweakers doorbrengt...) en bedacht dus een niet al te moeilijk voorbeeld van hoe je geheugen vrijwel errorvrij kon maken, en die ook nog snel zou zijn.
Natuurlijk kan je als je dingen slim aanpakt en dingen combineerd waarschijnlijk veel betere resultaten behalen qua hoeveelheid benodigde geheugen met dezelfde errorrate als resultaat...

Is dat soort errorcorrecting code trouwens al eens toegepast bij harde schijven / raid arrays???

--------