WEBVTT

00:00.120 --> 00:00.960
Instruktor: W

00:00.960 --> 00:03.000
tej lekcji omówimy pamięć ECC, znaną

00:03.000 --> 00:05.040
jako kod korekcji błędów.

00:05.040 --> 00:06.720
Najpierw jednak musimy omówić koncepcję

00:06.720 --> 00:10.020
braku parzystości i parzystości w odniesieniu do pamięci.

00:10.020 --> 00:12.000
Teraz, gdy mówimy o braku parzystości, jest to pamięć,

00:12.000 --> 00:14.160
która jest po prostu standardową pamięcią.

00:14.160 --> 00:16.200
Nie sprawdza błędów i pozwala na dowolne

00:16.200 --> 00:18.870
umieszczanie lub wyjmowanie danych z pamięci, a

00:18.870 --> 00:21.390
taka właśnie będzie większość pamięci.

00:21.390 --> 00:23.910
Pamięć nieparzysta jest bardzo tania w produkcji

00:23.910 --> 00:26.970
i ma wyższą prędkość niż pamięć parzysta.

00:26.970 --> 00:28.800
Z drugiej strony, pamięć parzystości będzie

00:28.800 --> 00:31.110
używana do przeprowadzania podstawowej kontroli

00:31.110 --> 00:32.610
błędów i zapewnienia niezawodności

00:32.610 --> 00:34.890
i integralności zawartości pamięci.

00:34.890 --> 00:35.910
Z tego powodu pamięć

00:35.910 --> 00:38.460
ta będzie wolniejsza niż pamięć nieparametryczna,

00:38.460 --> 00:40.440
ale charakteryzuje się niezawodnością,

00:40.440 --> 00:42.000
która jest niezbędna w serwerach

00:42.000 --> 00:44.910
i niektórych stacjach roboczych klasy high-end.

00:44.910 --> 00:47.220
Teraz pamięć, która ma kontrolę parzystości,

00:47.220 --> 00:49.320
będzie w stanie wykonać podstawowe obliczenia

00:49.320 --> 00:50.490
w oparciu o to, co widzi,

00:50.490 --> 00:52.920
aby sprawdzić, czy dane są dobre, czy nie.

00:52.920 --> 00:55.110
A jeśli te dane są dobre, wykorzysta je.

00:55.110 --> 00:57.240
A jeśli nie, wystąpi błąd, ale nie będzie

00:57.240 --> 00:58.560
w stanie go naprawić.

00:58.560 --> 01:00.750
Będzie mógł po prostu powiedzieć, że wystąpił

01:00.750 --> 01:02.460
błąd, ale nie wiem, jak go naprawić.

01:02.460 --> 01:04.860
Zasadniczo działa to w ten sposób, że każdy

01:04.860 --> 01:07.230
bajt ma powiązany z nim bit parzystości.

01:07.230 --> 01:10.230
Tak więc zamiast ośmiu bitów mamy teraz dziewięć bitów,

01:10.230 --> 01:13.860
ponieważ osiem bitów danych plus jeden bit parzystości.

01:13.860 --> 01:16.200
Teraz bit parzystości zostanie ustawiony we właściwym czasie.

01:16.200 --> 01:17.970
Następnie zostaną one obliczone i porównane

01:17.970 --> 01:19.830
podczas odczytu z pamięci, aby określić,

01:19.830 --> 01:21.420
czy którykolwiek z bitów zmienił się

01:21.420 --> 01:24.330
od czasu ostatniego zapisu danych w tej pamięci.

01:24.330 --> 01:25.470
Ten rodzaj sprawdzania jest

01:25.470 --> 01:28.470
jednak ograniczony do wykrywania błędów pojedynczych bitów.

01:28.470 --> 01:30.300
A jeśli dwa bity zostały zmienione, kontrola

01:30.300 --> 01:32.310
parzystości może faktycznie przejść pomyślnie,

01:32.310 --> 01:35.550
ponieważ pamiętaj, że bity mogą mieć tylko wartość 0 lub 1.

01:35.550 --> 01:38.850
Na przykład, powiedzmy, że zapisałem liczbę

01:38.850 --> 01:39.683
0, która jest

01:39.683 --> 01:44.460
zapisana jako 00000000 w systemie binarnym.

01:44.460 --> 01:47.700
Teraz, jeśli dodam wszystkie te bity razem, otrzymam osiem

01:47.700 --> 01:50.400
0, co daje mi 0 dla mojego bitu parzystości.

01:50.400 --> 01:52.560
Teraz, jeśli pójdę odczytać tę liczbę z

01:52.560 --> 01:54.090
pamięci i zobaczę, że jest osiem

01:54.090 --> 01:56.220
zer, dodam je do siebie i otrzymam 0, 0 pasuje

01:56.220 --> 01:58.050
do mojego bitu parzystości jako 0,

01:58.050 --> 01:59.850
więc są to dobre dane.

01:59.850 --> 02:00.720
Z drugiej strony,

02:00.720 --> 02:02.430
powiedzmy, że zapisuję

02:02.430 --> 02:07.200
liczbę 1, która jest zapisana jako 00000001.

02:07.200 --> 02:10.470
Jeśli dodam wszystkie te liczby do siebie, otrzymam 1.

02:10.470 --> 02:13.530
I umieszczę to w moim parytecie dziewiątego bitu.

02:13.530 --> 02:15.720
Robiąc to, czytam teraz z tego i

02:15.720 --> 02:17.133
dostaję 00000001.

02:19.560 --> 02:21.210
A ponieważ wszystko to sumuje

02:21.210 --> 02:22.410
się do 1 i pasuje do mojego

02:22.410 --> 02:24.060
bitu parzystości, wiem, że dane

02:24.060 --> 02:25.440
są dobre. Ale jeśli umieściłem

02:25.440 --> 02:27.240
to w pamięci i siedziało tam przez

02:27.240 --> 02:31.170
kilka godzin, a ta 1 została przypadkowo zmieniona na 0, jeśli teraz

02:31.170 --> 02:34.830
to przeczytam i otrzymam 00000000, i dodam je razem, otrzymam 0

02:34.830 --> 02:39.210
i porównam to z moim bitem parzystości, który miał w sobie 1, to teraz mówi mi,

02:39.210 --> 02:40.980
że wystąpił błąd i coś poszło nie

02:40.980 --> 02:42.510
tak.

02:42.510 --> 02:44.730
Nie wiem, który z tych ośmiu bitów został zmieniony,

02:44.730 --> 02:46.560
ale przynajmniej jeden z nich.

02:46.560 --> 02:47.580
Z drugiej strony,

02:47.580 --> 02:48.413
jeśli ta liczba

02:48.413 --> 02:52.260
z 00000001 została zmieniona na coś w rodzaju

02:52.260 --> 02:57.210
01010001, mam teraz dwa bity, które zostały przypadkowo

02:57.210 --> 02:58.950
zmienione z 0 na 1 przez

02:58.950 --> 03:01.590
pamięć.

03:01.590 --> 03:04.260
Kiedy patrzę na parzystość, nadal będzie to 1, ponieważ

03:04.260 --> 03:06.930
kiedy je sumuję, jeśli jest to liczba nieparzysta, będzie

03:06.930 --> 03:08.940
to 1 dla mojego bitu parzystości.

03:08.940 --> 03:10.770
A jeśli je zsumuję i będzie to liczba

03:10.770 --> 03:12.090
parzysta, będzie to 0.

03:12.090 --> 03:13.500
Jak więc widać, nie będziesz

03:13.500 --> 03:14.940
w stanie wykryć błędu, jeśli

03:14.940 --> 03:17.340
dwa bity zostały zmienione w tym miejscu, jeśli

03:17.340 --> 03:20.100
używasz obliczeń typu parzystości.

03:20.100 --> 03:23.490
Dobrą wiadomością jest to, że około 90% większości błędów

03:23.490 --> 03:25.770
to błędy jednobitowe, więc sprawdzanie

03:25.770 --> 03:28.080
parzystości zwykle wystarcza w większości

03:28.080 --> 03:30.000
naszych sytuacji.

03:30.000 --> 03:31.530
Ale jeśli masz do czynienia z czymś takim

03:31.530 --> 03:33.360
jak uruchamianie serwerów dla banku, posiadanie

03:33.360 --> 03:35.520
jakichkolwiek błędów może być złą rzeczą.

03:35.520 --> 03:37.890
Chcemy więc czegoś lepszego niż parzystość

03:37.890 --> 03:40.650
i tu właśnie do gry wkracza ECC.

03:40.650 --> 03:43.830
Teraz ECC to skrót od Error Correcting Code.

03:43.830 --> 03:45.930
Kod korekcji błędów to rodzaj pamięci,

03:45.930 --> 03:48.390
który przenosi parzystość na wyższy poziom.

03:48.390 --> 03:50.460
Teraz nie tylko może wykryć błąd,

03:50.460 --> 03:51.810
podobnie jak parzystość,

03:51.810 --> 03:54.780
ale może również skorygować ten błąd.

03:54.780 --> 03:57.300
Teraz ECC jest nieco wolniejsze niż parzystość, która

03:57.300 --> 03:59.490
jest również wolniejsza niż nieparzystość.

03:59.490 --> 04:00.990
Tak więc rezygnujesz z pewnej

04:00.990 --> 04:02.610
wydajności na rzecz tej dodatkowej

04:02.610 --> 04:04.290
możliwości, ale uzyskujesz wyższą

04:04.290 --> 04:06.300
integralność i niezawodność pamięci,

04:06.300 --> 04:07.950
gdy używasz ECC, ponieważ będzie

04:07.950 --> 04:11.760
ona w stanie wykryć te błędy i je naprawić.

04:11.760 --> 04:14.040
Ogólnie rzecz biorąc, kod ECC lub kod korekcji

04:14.040 --> 04:15.570
błędów jest używany tylko w naprawdę

04:15.570 --> 04:18.660
zaawansowanych stacjach roboczych lub serwerach ze względu

04:18.660 --> 04:20.190
na dodatkowe koszty, a ten dodatkowy

04:20.190 --> 04:22.500
wysoki poziom integralności jest potrzebny

04:22.500 --> 04:25.230
tylko w tego typu środowiskach.

04:25.230 --> 04:26.340
Teraz możesz się zastanawiać,

04:26.340 --> 04:28.980
w jaki sposób ECC faktycznie określa, co było nie

04:28.980 --> 04:30.990
tak i jak to naprawić?

04:30.990 --> 04:32.040
Aby to zrobić, użyje

04:32.040 --> 04:33.960
czegoś znanego jako pamięć buforowana

04:33.960 --> 04:35.700
lub zarejestrowana.

04:35.700 --> 04:37.980
Teraz pamięć buforowana lub zarejestrowana

04:37.980 --> 04:39.570
ma dodatkowy sprzęt, który będzie

04:39.570 --> 04:42.870
znajdował się między pamięcią a procesorem lub procesorem.

04:42.870 --> 04:44.850
Sprzęt ten nazywany jest rejestrem

04:44.850 --> 04:46.290
i przechowuje dane w buforze

04:46.290 --> 04:48.720
przed wysłaniem ich do procesora.

04:48.720 --> 04:50.760
Ta funkcja jest używana jako miara niezawodności

04:50.760 --> 04:51.990
w wielu systemach, zwłaszcza

04:51.990 --> 04:53.550
w systemach takich jak serwery, które

04:53.550 --> 04:55.380
mają wiele różnych modułów pamięci, w których

04:55.380 --> 04:56.910
mogą wystąpić błędy.

04:56.910 --> 04:59.730
Systemy te wymagają buforowania lub rejestrowania danych

04:59.730 --> 05:01.350
w celu zmniejszenia obciążenia elektrycznego

05:01.350 --> 05:02.370
wykorzystywanego przez

05:02.370 --> 05:04.680
te systemy, które mają duże ilości modułów pamięci,

05:04.680 --> 05:06.450
a to może być połączone z pamięcią parzystości

05:06.450 --> 05:08.220
lub kodem korekcji błędów, aby zapewnić

05:08.220 --> 05:10.140
dodatkową niezawodność, której szukasz

05:10.140 --> 05:13.020
i wykryć te błędy.

05:13.020 --> 05:15.510
Teraz, aby korzystać z modułów kodu korygującego

05:15.510 --> 05:18.840
błędy, płyta główna musi je obsługiwać, podobnie jak procesor.

05:18.840 --> 05:21.450
Jeśli któryś z tych komponentów nie obsługuje ECC,

05:21.450 --> 05:24.450
to nawet jeśli kupisz moduły ECC, które kosztują więcej,

05:24.450 --> 05:27.150
nie uzyskasz dodatkowych korzyści z ECC.

05:27.150 --> 05:28.800
Warto o tym pamiętać.

05:28.800 --> 05:32.700
Ponadto większość płyt głównych albo obsługuje ECC, albo nie.

05:32.700 --> 05:34.140
Generalnie nie ma takiej opcji.

05:34.140 --> 05:36.690
Jeśli więc kupisz płytę główną obsługującą ECC,

05:36.690 --> 05:38.940
będziesz musiał kupić moduły ECC, które

05:38.940 --> 05:41.490
są zarejestrowanymi modułami pamięci.

05:41.490 --> 05:44.160
Jeśli znajdziesz płytę główną obsługującą

05:44.160 --> 05:46.170
moduły ECC lub non-ECC, zazwyczaj

05:46.170 --> 05:49.110
nie będą one obsługiwać obu jednocześnie.

05:49.110 --> 05:51.570
Tak więc wszystkie moduły muszą być ECC

05:51.570 --> 05:53.880
lub żaden z modułów nie może być ECC.

05:53.880 --> 05:56.700
Ich mieszanka może powodować błędy w systemie, a płyta główna

05:56.700 --> 05:58.950
nie będzie wiedziała, jak sobie z nimi poradzić.

05:58.950 --> 06:00.210
Ostatnią rzeczą, o której

06:00.210 --> 06:02.370
chciałbym wspomnieć, jest to, że jeśli

06:02.370 --> 06:04.710
używasz DDR5, DDR5 ma pewną kontrolę błędów

06:04.710 --> 06:06.780
wewnątrz samych modułów.

06:06.780 --> 06:10.500
Nie jest to uważane za ECC lub moduł ECC.

06:10.500 --> 06:11.850
Tak więc korekcja błędów

06:11.850 --> 06:14.520
w nowszych modułach DDR5 może być używana na płytach

06:14.520 --> 06:17.160
głównych, które nie obsługują ECC i nadal będziesz

06:17.160 --> 06:19.710
mieć możliwość sprawdzania błędów.

06:19.710 --> 06:21.420
Jest to inna forma sprawdzania błędów

06:21.420 --> 06:23.910
i nie jest uważana za kod korygujący błędy.

06:23.910 --> 06:26.250
Należy więc o tym pamiętać i nie dać się zmylić,

06:26.250 --> 06:27.810
gdy jesteś w terenie.

06:27.810 --> 06:29.640
Jest to inna forma sprawdzania błędów,

06:29.640 --> 06:32.040
a moduły DDR5 nadal mogą być sprzedawane jako

06:32.040 --> 06:34.740
moduły ECC lub non-ECC, ponieważ oprócz tego wewnętrznego

06:34.740 --> 06:37.290
sprawdzania błędów, mogą one również współpracować

06:37.290 --> 06:39.840
z procesorem i płytą główną, jeśli obsługują one

06:39.840 --> 06:41.580
ECC i są teraz również kodem korygującym

06:41.580 --> 06:44.040
błędy.

06:44.040 --> 06:45.510
Wiem, że to trochę mylące.

06:45.510 --> 06:48.210
Pamiętaj więc o tym, gdy jesteś w terenie.