Wat betekenen de inscripties van RAM geheugen

In de volgende text weet ik eigenlijk niet van alles wat het betekend. Misschien kan iemand hiermee helpen.

Sodimm Ram DDR3 8 GB 1333 mhz 1.5 V geheugen Voor notebook PC3-10600S 204pin non-ECC Notebook RAM memoria

Het getal 10600? Is dat de snelheid in Mhz?
Wat bedoelen ze met non ECC?

De rest van de text is wel te begrijpen.

Dok

Golden Member

Even snel zoeken leverde dit op.

Nog iets verder gekeken en kwam dit ook tegen.

Wie niet horen wil moet TV kijken.
maartenbakker

Golden Member

PC is de "speed rating". Bij DDR3 worden er op elke klok 8 bytes opgehaald, vandaar dat 1333MHz zich na afronding vertaalt naar PC10600. Ik gebruik zelf altijd gewoon de klokfrequentie, dat is een stuk duidelijker.

Non-ECC betekent dat elke byte in 8 bits wordt opgeslagen, zonder controle op omgevallen bitjes. Voor servers gebruik je ECC waarbij bitfouten gesignaleerd en vaak gecorrigeerd worden. In een heel lang verleden werden daar "parity bits" voor gebruikt, dus 9 bits per byte, maar ECC is wat geavanceerder.

www.elba-elektro.nl | "The mind is a funny thing. Sometimes it needs a good whack on the side of the head to jar things loose."

Bedankt. Grappig dat Ecc dus zoiets is als het aloude parity bit.

Maar weer even iets geleerd. Voor de ouderwetse 8 en 16 bit Cpu's wit ik vroeger exact hoe alles werd aangegeven. Ik ben alleen op een gegeven moment mijn belangstelling voor dit soort van dingen een beetje verloren. Meeste computers waren op een bepaald moment wel snel genoeg en hadden genoeg geheugen. De kretologie werd steeds mooier en spannender voor ongeveer hetzelfde. Zodoende vond ik het niet heel interessant meer om alles bij te houden.

Alleen wilde ik nu eens echt weten wat ze met al die kreten en nummertjes bedoelen. Het is een beetje stom om van commerciële reclame websites afhankelijk te zijn om het juiste geheugentype te kiezen voor je computer zonder dat je echt weet wat je eigenlijk gaan kopen.

Er staat nu dus de kloksnelheid op, of een getal dat de kloksnelheid vermenigvuldigd met het aantal bytes dat per klokpuls wordt opgehaald is. Dat om het moeilijk te maken of juist commercieel aantrekkelijk. ;(

Non-ECC betekent dat elke byte in 8 bits wordt opgeslagen, zonder controle op omgevallen bitjes. Voor servers gebruik je ECC waarbij bitfouten gesignaleerd en vaak gecorrigeerd worden. In een heel lang verleden werden daar "parity bits" voor gebruikt, dus 9 bits per byte, maar ECC is wat geavanceerder.

Ooit heb ik een server PC gehad waar je een extra parity rambank bij kon prikken. Daar zat het dus niet in de memory modules. Ik begrijp overigens dat dit ecc gebeuren iets complexer is als een gewone parity check.

Arco

Special Member

ECC memory wordt volgens mij (hoofdzakelijk in servers) al meer als 25 jaar gebruikt...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
mel

Golden Member

Er zijn tegenwoordig veel kreten waar je nog nooit van gehoord heb, en die nergens op slaan..
Als je maar de helft begrijpt, dan ben je knap..

u=ir betekent niet :U bent ingenieur..
Sine

Moderator

Het enige vreemde is wellicht de "PC3-10600S", de rest zijn standaard kreten van +10jaar geleden.

Op 15 april 2019 01:42:52 schreef Ex-fietser:
Ik ben alleen op een gegeven moment mijn belangstelling voor dit soort van dingen een beetje verloren. Meeste computers waren op een bepaald moment wel snel genoeg en hadden genoeg geheugen.

idem hier, kende alle termen behalve die 10600S.
destijds ging het met grote stappen voorruit, als je van 75 naar 133MHz ging, was dat een wereld van verschil (1jaar tijd ertussen ongeveer)
als je van 8MB naar 32MB ram ging, ging een nieuwe wereld open van snelle computers.

maar tegenwoordig.
ik start windows 10 op mijn 14jaar oude laptop (denk core duo van 1,73GHz) met 2GB ram even snel op als mijn allernieuwste pc op het werk (8GB ram en geen idee wat voor CPU: i5, i7...).
Dat ding op het werk blijft evenveel hangen op youtube of andere websites, als mijn barrel thuis.
het enige nadeel: als ik zo 10 programmas open heb (15 tabbladen in chrome, outlook, word, putty, telegram, explorer, ftp programma, arduino IDE...) begint mijn thuis pc te klagen dat die onvoldoende werkgeheugen vrij heeft en vraagt om applicaties te sluiten. en ik negeer dat compleet. ding staat non stop aan, reboot die nooit.

bij mij thuis nemen alle browser processen (per tabblad dus 1) slechts een 35-40MB in (ook op de pc die ik hier nu aan de kust gebruik). op het werk nemen die tabbladen tussen de 150 en 400MB in. daar is het zelf zo erg dat chrome begint te hangen na een paar dagen, en dan kill ik alle processen van meer dan 250MB. die tabbladen refreshen dan en de pc gaat weer vlot.

dat is al helemaal absurd, je hebt dan veel geheugen, wordt het gewoon nutteloos ingevuld en dan begint de pc te hangen, en een oudere pc heeft er geen last van.

er is maar 1 ding waar mijn werk pc beter in is, videobeelden compresseren naar H264. die doet 20min ofzo voor 30min video, mijn pc thuis doet 5uur voor datzelfde filmpje (die doet dat snachts)

ik hou van werken ..., ik kan er uren naar kijken

Dat men tegenwoordig ECC gebruikt ipv parity kan ik wel uitleggen.

Zoals Maarten al zegt: De data wordt 8-bytes-tegelijk opgehaald. Als iedere byte een negende bit heeft zijn dat samen 8 extra bits.

Stel dat ik 64 bits heb en ik verklap je dat er precies 1 fout is opgetreden hoeveel bitjes heb je dan nodig om aan een volgend systeem door te geven welk bitje dat geweest is? Het antwoord is "ongeveer 6". Met 6 bitjes kan je aangeven WELKE van de 64 fout is. Van een fout bitje hoef je niet op te geven of ie 0 of 1 is geweest: als ie fout is dan moet ie de andere waarde gehad hebben.

Maar nu zijn er niet 64 bits maar 64+6. En de mogelijkheid "geen fout" moet ook nog aangegeven worden. Je hebt dus minimaal 7 bits nodig om dit alles te kunnen coderen. Nu heeft men tijden geleden inderdaad een manier gevonden om met 7 controle bitjes per 64 databits 1 fout te kunnen corrigeren. Als ik het goed heb was dat "reed-solomon": twee kerels die dat samen uitgevonden hebben.

Als je het simpeler aanpakt kan je het princiepe van fout-corectie inzien, het werkelijke reed-solomon is efficienter (heeft minder extra bits nodig) maar doet precies hetzelfde.

Die 64 databits kan je in een matrix zetten van 8x8 bits. Van iedere horizontale rij neem je de parity en zet je er rechts naast. Van iedere kolom neem je de parity en die zet je er onder. Nu heb je 16 extra bits. Als er dan in rij 3, kolom 5 een fout optreed dan zal je precies de parity van rij 3 en die van kolom 5 zien dat die niet meer kloppen. Flip je het bitje op 3,5 dan klopt alles weer. Treed er nog een fout bitje op, dan kunnen er twee situaties ontstaan. Als het op dezelfde rij of kolom gebeurt, dan flipt de rij-of-kolom parity weer naar "goed" en weet je niet op welke rij deze twee fouten hebben plaatsgevonden. Gebeurt het op een andere rij EN kolom , bijvoorbeeld rij4, kolom 6, dan weet je dat er een probleem zit in rij 3 en 4, en in kolom 5 en 6, maar niet welke combinatie. Dat kan 3,5 en 4,6 zijn of 3,6 en 4,5. Kortom, bij twee fouten zie je nog wel dat er IETS is misgegaan maar niet wat.

Deze methode werd tot niet zo heel lang geleden op flash geheugens toegepast, maar dan met grotere groepen van bitjes. (4096 bits).

Tegenwoordig is men wiskundig NOG een stapje verder dan reed-solomon. Stel je hebt 4096 bits en er zitten TWEE fouten in. Hoeveel mogelijkheden zijn er dan? Dan zijn er 4096*4095/2 mogelijke combinaties van 2 fouten. Samen met 4096 enkele fouten en 1 "alles goed" heb je iets van 24 bits nodig om dat te coderen. Maar als je 512 bytes met ieder een parity hebt, dan heb je maarliefst 512 bits waar je wat mee kan. Ruimschoots meer dan de 24 die je voor 2 fouten nodig hebt. Met de modernste wiskunde kunnen ze gewoon zoveel bitjes aan controle toevoegen zodat je ook inderdaad voor 4096 bits ongeveer per 12 toegevoegde bits ongeveer 1 extra fout kan tolereren. Dit is wat moderne flash geheugens doen. De fabrikant zegt dat je per 4096 bits zelden meer dan 8 fouten hebt, en dan gebruiken ze een code die 13 fouten kan corrigeren door 176 check bits toe te voegen.

Het maken van de check bits is niet het grootste probleem: dat is relatief eenvoudig. Bijvoorbeeld een MD5sum en dan de laagste zoveel bitjes opslaan zal best aardig werken. Maar met 1 fout kan je als computer makkelijk alle mogelijke 1-fout situaties aflopen en controleren of dat hem misschien was. Met 2 fouten tegelijk kan dat ook nog net, maar met meer wordt het al heel snel veel te veel rekenwerk. De slimmigheid zit hem daarin dat je met een redelijke berekening kan uitkomen op "dan zitten de fouten in posities x,y,z, u, v en w.".

Merk op dat moderne flash geheugens gewoon HEEL regelmatig fouten hebben. Denk aan gemiddeld iets van vier bits per 4096 opgeslagen bits. (denk aan 50/50 tussen: "niets aan de hand" en "8 fouten"!) Dus als je je SSD op 300Mbyte per seconde aan het uitlezen bent, dan is er niet veel tijd om de fouten te corrigeren! En dat moet dus HEEL regelmatig wel gebeuren. Als er 1x per uur een keertje een fout in zou zitten waardoor je dan die ene keer 1s moet wachten is dat geen probleem. Maar nu zit er (bij 300Mbyte/s) tienduizenden keren per seconde een te corrigeren fout in. Dat moet snel.

Dat is de stand van zaken betreffende ECC.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Zeer interessant verhaal REW. Bedankt.

Ik wist dat er ontwikkelingen waren in deze systemen. Alleen wist ik geen details.

Op een mechanische hardeschijf zit ook een dergelijk systeem. Volgens mij zit dat er al op vanaf de eerste schijven.

De data dichtheid is zo enorm en er wordt met zulke snelheden uitgelezen en geschreven dat het alleen al statistisch gezien gezien onmogelijk is dat er nooit een bitje om zal vallen. Een spike of andere electrische srtoring is al meer dan voldoende om iets te laten veranderen.