WEBVTT

00:00.120 --> 00:00.960
Instructeur: In deze

00:00.960 --> 00:03.000
les gaan we het hebben over ECC geheugen,

00:03.000 --> 00:05.040
bekend als foutcorrigerende code.

00:05.040 --> 00:06.720
Maar eerst moeten we het concept van

00:06.720 --> 00:10.020
non-pariteit en pariteit in termen van geheugen behandelen.

00:10.020 --> 00:12.000
Als we het nu hebben over niet-pariteit, dan

00:12.000 --> 00:14.160
is dit geheugen gewoon standaard geheugen.

00:14.160 --> 00:16.200
Het controleert niet op fouten en staat toe dat gegevens

00:16.200 --> 00:18.870
naar believen in het geheugen worden geplaatst of eruit worden

00:18.870 --> 00:21.390
gehaald en dit is wat het meeste geheugen zal zijn.

00:21.390 --> 00:23.910
Niet-pariteitsgeheugen is erg goedkoop om te maken

00:23.910 --> 00:26.970
en het heeft een hogere snelheid dan pariteitsgeheugen.

00:26.970 --> 00:28.800
Het pariteitsgeheugen daarentegen wordt

00:28.800 --> 00:31.110
gebruikt om basisfoutcontroles uit te voeren en

00:31.110 --> 00:32.610
om ervoor te zorgen dat de geheugeninhoud

00:32.610 --> 00:34.890
betrouwbaar en integer is.

00:34.890 --> 00:35.910
Hierdoor zal dit geheugen

00:35.910 --> 00:38.460
langzamer zijn dan niet-pariteitsgeheugen,

00:38.460 --> 00:40.440
maar het heeft wel de betrouwbaarheid

00:40.440 --> 00:42.000
die nodig is voor servers en bepaalde

00:42.000 --> 00:44.910
high-end desktop werkstations.

00:44.910 --> 00:47.220
Nu kan een geheugen met een pariteitscontrole

00:47.220 --> 00:49.320
een basisberekening uitvoeren op basis

00:49.320 --> 00:50.490
van wat het ziet om te controleren

00:50.490 --> 00:52.920
of de gegevens goed zijn of niet.

00:52.920 --> 00:55.110
En als die gegevens goed zijn, zullen ze worden gebruikt.

00:55.110 --> 00:57.240
En als dat niet zo is, treedt er een fout op, maar kan

00:57.240 --> 00:58.560
deze niet worden opgelost.

00:58.560 --> 01:00.750
Het zal gewoon kunnen zeggen dat er hier een fout is, maar

01:00.750 --> 01:02.460
ik weet niet hoe ik het moet oplossen.

01:02.460 --> 01:04.860
In principe werkt dit door aan elke byte

01:04.860 --> 01:07.230
een pariteitsbit te koppelen.

01:07.230 --> 01:10.230
Dus in plaats van acht bits, heb je nu negen bits,

01:10.230 --> 01:13.860
want acht databits plus één bit voor pariteit.

01:13.860 --> 01:16.200
Nu wordt de pariteitsbit op het juiste moment ingesteld.

01:16.200 --> 01:17.970
En dan wordt het berekend en vergeleken

01:17.970 --> 01:19.830
wanneer je uit het geheugen leest om te bepalen

01:19.830 --> 01:21.420
of er bits zijn veranderd sinds die gegevens

01:21.420 --> 01:24.330
voor het laatst in het geheugen zijn geschreven.

01:24.330 --> 01:25.470
Dit type controle is echter

01:25.470 --> 01:28.470
beperkt tot het detecteren van die enkele bitfouten.

01:28.470 --> 01:30.300
En als er twee bits zijn gewijzigd,

01:30.300 --> 01:32.310
kan die pariteitscontrole wel slagen,

01:32.310 --> 01:35.550
want onthoud dat bits alleen een 0 of een 1 kunnen zijn.

01:35.550 --> 01:38.850
Laten we bijvoorbeeld zeggen dat ik het getal

01:38.850 --> 01:39.683
0 heb opgeslagen,

01:39.683 --> 01:44.460
dat in het binair wordt geschreven als 00000000.

01:44.460 --> 01:47.700
Als ik nu al deze bits bij elkaar optel, krijg ik acht 0's

01:47.700 --> 01:50.400
en dat geeft me 0 voor mijn pariteitsbit.

01:50.400 --> 01:52.560
Als ik nu dat getal uit het geheugen ga lezen

01:52.560 --> 01:54.090
en ik zie dat er acht 0's zijn,

01:54.090 --> 01:56.220
dan tel ik die bij elkaar op en krijg ik 0, 0

01:56.220 --> 01:58.050
komt overeen met mijn pariteitsbit

01:58.050 --> 01:59.850
als 0, dus dit is goede data.

01:59.850 --> 02:00.720
Aan de andere

02:00.720 --> 02:02.430
kant, stel dat ik het getal

02:02.430 --> 02:07.200
1 opschrijf, dat wordt geschreven als 00000001.

02:07.200 --> 02:10.470
Als ik nu al deze getallen bij elkaar optel, krijg ik 1.

02:10.470 --> 02:13.530
En dat zet ik in mijn pariteit van het negende stukje.

02:13.530 --> 02:15.720
Door dit te doen, lees ik nu daaruit

02:15.720 --> 02:17.133
en krijg ik 00000001.

02:19.560 --> 02:21.210
En omdat alles bij elkaar opgeteld

02:21.210 --> 02:22.410
1 is en dat overeenkomt

02:22.410 --> 02:24.060
met mijn pariteitsbit, weet ik

02:24.060 --> 02:25.440
dat de gegevens goed zijn.

02:25.440 --> 02:27.240
Maar als ik dat in het geheugen zet en

02:27.240 --> 02:29.910
het heeft daar een paar uur gezeten en die 1 is per ongeluk

02:29.910 --> 02:31.170
veranderd in een 0, als ik

02:31.170 --> 02:34.830
dat nu lees en ik krijg 00000000, en ik tel die bij elkaar op, dan krijg ik

02:34.830 --> 02:36.420
0, en ik vergelijk dat met mijn

02:36.420 --> 02:37.830
pariteitsbit waar een 1 in zat,

02:37.830 --> 02:39.210
dan vertelt me dat er een fout

02:39.210 --> 02:42.510
is gemaakt en dat er iets is misgegaan.

02:42.510 --> 02:44.730
Ik weet niet welke van die acht bits zijn veranderd,

02:44.730 --> 02:46.560
maar in ieder geval één ervan.

02:46.560 --> 02:47.580
Aan de andere

02:47.580 --> 02:48.413
kant, als

02:48.413 --> 02:52.260
dat getal van 00000001 werd veranderd in iets

02:52.260 --> 02:57.210
als 01010001, had ik nu twee bits die per ongeluk door het

02:57.210 --> 02:58.950
geheugen van 0 naar

02:58.950 --> 03:01.590
1 waren veranderd.

03:01.590 --> 03:04.260
Als ik naar mijn pariteit kijk, wordt het nog steeds een

03:04.260 --> 03:06.930
1, want als ik die optel en het is een oneven getal, wordt

03:06.930 --> 03:08.940
het een 1 voor mijn pariteitsbit.

03:08.940 --> 03:10.770
En als ik die optel en het is een even getal,

03:10.770 --> 03:12.090
dan wordt het een 0.

03:12.090 --> 03:13.500
Dus zoals je kunt zien, zul je

03:13.500 --> 03:14.940
niet in staat zijn om een fout te

03:14.940 --> 03:17.340
detecteren als hierbinnen twee bits zijn veranderd

03:17.340 --> 03:20.100
als je een pariteitstype berekening gebruikt.

03:20.100 --> 03:23.490
Het goede nieuws is dat ongeveer 90% van de meeste fouten een fout

03:23.490 --> 03:25.770
van het type enkele bit zal zijn, zodat pariteitscontrole

03:25.770 --> 03:28.080
meestal voldoende is voor de meeste van onze

03:28.080 --> 03:30.000
situaties.

03:30.000 --> 03:31.530
Maar als je te maken hebt met iets als het

03:31.530 --> 03:33.360
draaien van servers voor een bank, kunnen fouten

03:33.360 --> 03:35.520
van welke aard dan ook een slechte zaak zijn.

03:35.520 --> 03:37.890
We willen dus iets beters dan pariteit

03:37.890 --> 03:40.650
en dat is waar ECC om de hoek komt kijken.

03:40.650 --> 03:43.830
ECC staat nu voor Error Correcting Code.

03:43.830 --> 03:45.930
Een foutcorrigerende code is het type geheugen

03:45.930 --> 03:48.390
dat pariteit naar een hoger niveau tilt.

03:48.390 --> 03:50.460
Nu kan het niet alleen een fout detecteren,

03:50.460 --> 03:51.810
net zoals pariteit dat kan,

03:51.810 --> 03:54.780
maar het kan die fout ook voor je corrigeren.

03:54.780 --> 03:57.300
ECC is iets langzamer dan pariteit, wat ook

03:57.300 --> 03:59.490
langzamer is dan niet-pariteit.

03:59.490 --> 04:00.990
En dus lever je wat prestaties

04:00.990 --> 04:02.610
in voor deze extra mogelijkheid,

04:02.610 --> 04:04.290
maar je krijgt een hogere integriteit

04:04.290 --> 04:06.300
en betrouwbaarheid van je geheugen

04:06.300 --> 04:07.950
als je ECC gebruikt, omdat het

04:07.950 --> 04:11.760
die fouten kan detecteren en herstellen.

04:11.760 --> 04:14.040
Over het algemeen zie je ECC of foutcorrigerende

04:14.040 --> 04:15.570
code alleen gebruikt worden

04:15.570 --> 04:18.660
in echt high-end werkstations of servers vanwege de

04:18.660 --> 04:20.190
extra kosten en dat extra hoge

04:20.190 --> 04:22.500
integriteitsniveau is alleen nodig in

04:22.500 --> 04:25.230
dat soort omgevingen.

04:25.230 --> 04:26.340
Nu vraag je je misschien

04:26.340 --> 04:28.980
af: hoe bepaalt ECC eigenlijk wat er mis was

04:28.980 --> 04:30.990
en hoe het te repareren?

04:30.990 --> 04:32.040
Om dat te doen, gebruikt

04:32.040 --> 04:33.960
het iets dat bekend staat als gebufferd

04:33.960 --> 04:35.700
of geregistreerd geheugen.

04:35.700 --> 04:37.980
Gebufferd geheugen of geregistreerd

04:37.980 --> 04:39.570
geheugen heeft extra hardware

04:39.570 --> 04:42.870
tussen het geheugen en je CPU of processor.

04:42.870 --> 04:44.850
Deze hardware wordt een register genoemd

04:44.850 --> 04:46.290
en slaat gegevens op in een buffer

04:46.290 --> 04:48.720
voordat ze naar de CPU worden gestuurd.

04:48.720 --> 04:50.760
Deze functie wordt gebruikt als betrouwbaarheidsmaatregel

04:50.760 --> 04:51.990
in veel systemen, vooral in systemen

04:51.990 --> 04:53.550
zoals servers die veel verschillende

04:53.550 --> 04:55.380
geheugenmodules hebben waar fouten kunnen

04:55.380 --> 04:56.910
optreden.

04:56.910 --> 04:59.730
Deze systemen vereisen buffering of registratie van de gegevens om

04:59.730 --> 05:01.350
de elektrische belasting te verminderen

05:01.350 --> 05:02.370
die wordt gebruikt door deze

05:02.370 --> 05:04.680
systemen die grote hoeveelheden geheugenmodules hebben,

05:04.680 --> 05:06.450
en dit kan worden gecombineerd met pariteitsgeheugen

05:06.450 --> 05:08.220
of geheugen met foutcorrectiecode om je die

05:08.220 --> 05:10.140
extra betrouwbaarheid te geven waar je naar op

05:10.140 --> 05:13.020
zoek bent en die fouten te detecteren.

05:13.020 --> 05:15.510
Om foutcorrigerende codemodules te kunnen gebruiken,

05:15.510 --> 05:18.840
moet je moederbord dit ondersteunen, net als je CPU.

05:18.840 --> 05:21.450
Als een van deze componenten ECC niet ondersteunt,

05:21.450 --> 05:24.450
dan krijg je zelfs als je de ECC modules koopt die meer

05:24.450 --> 05:27.150
kosten, niet dat extra ECC voordeel.

05:27.150 --> 05:28.800
Houd daar dus rekening mee.

05:28.800 --> 05:32.700
De meeste moederborden ondersteunen ECC of niet.

05:32.700 --> 05:34.140
Over het algemeen is dat geen optie.

05:34.140 --> 05:36.690
Dus als je een moederbord koopt dat ECC ondersteunt,

05:36.690 --> 05:38.940
moet je ECC-modules kopen, dat zijn die

05:38.940 --> 05:41.490
geregistreerde geheugenmodules.

05:41.490 --> 05:44.160
Als je een moederbord vindt dat ECC- of niet-ECC-modules

05:44.160 --> 05:46.170
ondersteunt, ondersteunen ze beide

05:46.170 --> 05:49.110
modules meestal niet tegelijkertijd.

05:49.110 --> 05:51.570
Dus al uw modules moeten ECC zijn of

05:51.570 --> 05:53.880
geen van uw modules kan ECC zijn.

05:53.880 --> 05:56.700
Als je er een mix van hebt, kan dat fouten veroorzaken in het systeem en

05:56.700 --> 05:58.950
weet het moederbord niet hoe het ermee om moet gaan.

05:58.950 --> 06:00.210
Het laatste dat ik wil

06:00.210 --> 06:02.370
noemen is dat als je DDR5 gebruikt, DDR5

06:02.370 --> 06:04.710
een aantal foutcontroles heeft die intern

06:04.710 --> 06:06.780
in de modules zelf zitten.

06:06.780 --> 06:10.500
Dit wordt niet beschouwd als ECC of een ECC-module.

06:10.500 --> 06:11.850
En dus kan deze foutcorrectie

06:11.850 --> 06:14.520
in de nieuwere DDR5-modules worden gebruikt op moederborden

06:14.520 --> 06:17.160
die ECC niet ondersteunen en heb je nog steeds enige

06:17.160 --> 06:19.710
foutcontrole mogelijkheid.

06:19.710 --> 06:21.420
Dit is een andere vorm van foutcontrole

06:21.420 --> 06:23.910
en wordt niet beschouwd als foutcorrigerende code.

06:23.910 --> 06:26.250
Houd daar dus rekening mee en laat je niet in verwarring

06:26.250 --> 06:27.810
brengen als je in het veld bent.

06:27.810 --> 06:29.640
Dit is een andere vorm van foutcontrole

06:29.640 --> 06:32.040
en DDR5-modules kunnen nog steeds worden

06:32.040 --> 06:34.740
verkocht als ECC- of niet-ECC-modules, omdat ze

06:34.740 --> 06:37.290
naast die interne foutcontrole ook kunnen samenwerken

06:37.290 --> 06:39.840
met de CPU en het moederbord als die ECC ondersteunen

06:39.840 --> 06:41.580
en ze nu ook foutcorrigerende code

06:41.580 --> 06:44.040
hebben.

06:44.040 --> 06:45.510
Ik weet dat het een beetje verwarrend wordt.

06:45.510 --> 06:48.210
Wees je daar dus van bewust als je in het veld bent.