WEBVTT

00:00.120 --> 00:00.960
Instrutor: Nesta

00:00.960 --> 00:03.000
lição, falaremos sobre a memória ECC, conhecida

00:03.000 --> 00:05.040
como código de correção de erros.

00:05.040 --> 00:06.720
Mas, primeiro, precisamos abordar

00:06.720 --> 00:10.020
o conceito de não-paridade e paridade em termos de memória.

00:10.020 --> 00:12.000
Agora, quando falamos de não-paridade, essa

00:12.000 --> 00:14.160
é uma memória que é apenas uma memória padrão.

00:14.160 --> 00:16.200
Ele não verifica se há erros e permite que

00:16.200 --> 00:18.870
os dados sejam colocados ou retirados da memória à vontade,

00:18.870 --> 00:21.390
e é isso que a maioria das memórias será.

00:21.390 --> 00:23.910
A fabricação da memória não paritária é muito barata

00:23.910 --> 00:26.970
e sua velocidade é maior do que a da memória paritária.

00:26.970 --> 00:28.800
A memória de paridade, por outro lado, será

00:28.800 --> 00:31.110
usada para realizar a verificação básica de erros

00:31.110 --> 00:32.610
e garantir que o conteúdo da memória

00:32.610 --> 00:34.890
seja confiável e tenha integridade.

00:34.890 --> 00:35.910
Por esse motivo, essa

00:35.910 --> 00:38.460
memória será mais lenta do que a memória não-paritária,

00:38.460 --> 00:40.440
mas tem a confiabilidade necessária para

00:40.440 --> 00:42.000
servidores e determinadas estações

00:42.000 --> 00:44.910
de trabalho de desktop de ponta.

00:44.910 --> 00:47.220
Agora, a memória que tem uma verificação de paridade

00:47.220 --> 00:49.320
será capaz de fazer um cálculo básico com base

00:49.320 --> 00:50.490
no que está vendo para verificar

00:50.490 --> 00:52.920
se os dados são bons ou não.

00:52.920 --> 00:55.110
E se esses dados forem bons, ele os utilizará.

00:55.110 --> 00:57.240
E se não for, ocorrerá um erro, mas não será

00:57.240 --> 00:58.560
possível corrigi-lo.

00:58.560 --> 01:00.750
Ele só poderá dizer que há um erro aqui,

01:00.750 --> 01:02.460
mas não sei como corrigi-lo.

01:02.460 --> 01:04.860
Basicamente, isso funciona pelo fato de cada

01:04.860 --> 01:07.230
byte ter um bit de paridade associado a ele.

01:07.230 --> 01:10.230
Portanto, em vez de ter oito bits, agora você tem nove

01:10.230 --> 01:13.860
bits, porque oito bits de dados mais um bit para paridade.

01:13.860 --> 01:16.200
Agora, esse bit de paridade será definido no momento certo.

01:16.200 --> 01:17.970
Em seguida, ele será calculado e comparado

01:17.970 --> 01:19.830
quando você ler da memória para determinar

01:19.830 --> 01:21.420
se algum dos bits foi alterado desde

01:21.420 --> 01:24.330
a última vez que os dados foram gravados na memória.

01:24.330 --> 01:25.470
No entanto, esse tipo de

01:25.470 --> 01:28.470
verificação se limita a detectar esses erros de bit único.

01:28.470 --> 01:30.300
E se houver dois bits que foram alterados,

01:30.300 --> 01:32.310
a verificação de paridade poderá ser aprovada,

01:32.310 --> 01:35.550
pois lembre-se de que os bits só podem ser 0 ou 1.

01:35.550 --> 01:39.683
Por exemplo, digamos que eu tenha armazenado

01:39.683 --> 01:44.460
o número 0, que é escrito como 00000000 em binário.

01:44.460 --> 01:47.700
Agora, se eu somar todos esses bits, obtenho oito

01:47.700 --> 01:50.400
0s, o que me dá 0 como bit de paridade.

01:50.400 --> 01:52.560
Agora, se eu for ler esse número da memória

01:52.560 --> 01:54.090
e vir que há oito 0s, eu os somo

01:54.090 --> 01:56.220
e obtenho 0, 0 corresponde ao meu bit

01:56.220 --> 01:58.050
de paridade como 0, portanto, esses

01:58.050 --> 01:59.850
dados são bons.

01:59.850 --> 02:00.720
Agora, por outro

02:00.720 --> 02:02.430
lado, digamos que eu estivesse

02:02.430 --> 02:07.200
escrevendo o número 1, que é escrito como 00000001.

02:07.200 --> 02:10.470
Agora, se eu somar todos esses números, vou obter 1.

02:10.470 --> 02:13.530
E colocarei isso em minha parte de paridade da nona parte.

02:13.530 --> 02:15.720
Ao fazer isso, agora leio a partir daí

02:15.720 --> 02:17.133
e recebo 00000001.

02:19.560 --> 02:21.210
Mas se eu colocasse isso

02:21.210 --> 02:22.410
na memória e ficasse

02:22.410 --> 02:24.060
lá por algumas horas e

02:24.060 --> 02:25.440
esse 1 fosse alterado

02:25.440 --> 02:27.240
para 0 por acidente, se

02:27.240 --> 02:31.170
eu lesse agora e obtivesse 00000000, somasse esses

02:31.170 --> 02:34.830
dados e obtivesse 0 e comparasse com meu bit de

02:34.830 --> 02:39.210
paridade, que tinha um 1, isso me diria que houve um erro

02:39.210 --> 02:42.510
e que algo deu errado.

02:42.510 --> 02:44.730
Não sei quais desses oito bits foram alterados,

02:44.730 --> 02:46.560
mas pelo menos um deles foi.

02:46.560 --> 02:47.580
Por outro lado,

02:47.580 --> 02:48.413
se esse número

02:48.413 --> 02:52.260
de 00000001 fosse alterado para algo como 01010001,

02:52.260 --> 03:01.590
eu teria agora dois bits que foram alterados de 0s para 1 por acidente pela memória.

03:01.590 --> 03:04.260
Quando olho para a minha paridade, ela ainda será

03:04.260 --> 03:06.930
1 porque, quando eu as somar, se for um número ímpar,

03:06.930 --> 03:08.940
será 1 para o meu bit de paridade.

03:08.940 --> 03:10.770
E se eu somar esses valores e for um

03:10.770 --> 03:12.090
número par, será um 0.

03:12.090 --> 03:13.500
Portanto, como você pode ver,

03:13.500 --> 03:14.940
não será possível detectar um

03:14.940 --> 03:17.340
erro se dois bits forem alterados dentro disso se

03:17.340 --> 03:20.100
você estiver usando um cálculo de tipo de paridade.

03:20.100 --> 03:23.490
Agora, a boa notícia é que cerca de 90% da maioria dos erros serão

03:23.490 --> 03:25.770
do tipo de bit único e, portanto, a verificação

03:25.770 --> 03:28.080
de paridade geralmente é suficiente para

03:28.080 --> 03:30.000
a maioria das situações.

03:30.000 --> 03:31.530
Mas se você estiver lidando com algo

03:31.530 --> 03:33.360
como a execução de servidores para um banco,

03:33.360 --> 03:35.520
ter qualquer tipo de erro pode ser algo ruim.

03:35.520 --> 03:37.890
Portanto, queremos algo melhor do que

03:37.890 --> 03:40.650
a paridade, e é aí que o ECC entra em ação.

03:40.650 --> 03:43.830
Agora, ECC significa Error Correcting Code (código de correção de erros).

03:43.830 --> 03:45.930
Um código de correção de erros é o tipo de memória

03:45.930 --> 03:48.390
que eleva a paridade ao próximo nível.

03:48.390 --> 03:50.460
Agora, além de detectar a existência de

03:50.460 --> 03:51.810
um erro, assim como a paridade,

03:51.810 --> 03:54.780
ele também pode corrigir esse erro para você.

03:54.780 --> 03:57.300
Agora, o ECC é um pouco mais lento do que a paridade, que

03:57.300 --> 03:59.490
também é mais lenta do que a não-paridade.

03:59.490 --> 04:00.990
Portanto, você está abrindo

04:00.990 --> 04:02.610
mão de um pouco de desempenho em

04:02.610 --> 04:04.290
troca desse recurso extra, mas

04:04.290 --> 04:06.300
está obtendo maior integridade e confiabilidade

04:06.300 --> 04:07.950
da memória ao usar o ECC, pois ele

04:07.950 --> 04:09.900
será capaz de detectar e corrigir esses

04:09.900 --> 04:11.760
erros.

04:11.760 --> 04:14.040
Em geral, você só verá o ECC ou o código de correção

04:14.040 --> 04:15.570
de erros sendo usado em estações

04:15.570 --> 04:18.660
de trabalho ou servidores realmente sofisticados devido

04:18.660 --> 04:20.190
ao custo adicional, e esse alto

04:20.190 --> 04:22.500
nível extra de integridade só é necessário

04:22.500 --> 04:25.230
nesses tipos de ambientes.

04:25.230 --> 04:26.340
Agora você deve estar

04:26.340 --> 04:28.980
se perguntando: como o ECC realmente determina o que

04:28.980 --> 04:30.990
estava errado e como corrigi-lo?

04:30.990 --> 04:32.040
Bem, para fazer isso, ele

04:32.040 --> 04:33.960
usará algo conhecido como memória armazenada

04:33.960 --> 04:35.700
em buffer ou registrada.

04:35.700 --> 04:37.980
Agora, a memória com buffer ou memória registrada

04:37.980 --> 04:39.570
tem um hardware adicional que

04:39.570 --> 04:42.870
fica entre a memória e a CPU ou o processador.

04:42.870 --> 04:44.850
Esse hardware é chamado de registro

04:44.850 --> 04:46.290
e armazena dados em um buffer

04:46.290 --> 04:48.720
antes de serem enviados à CPU.

04:48.720 --> 04:50.760
Esse recurso é usado como medida de confiabilidade

04:50.760 --> 04:51.990
em muitos sistemas, especialmente

04:51.990 --> 04:53.550
em sistemas como servidores que têm

04:53.550 --> 04:55.380
muitos módulos de memória diferentes onde

04:55.380 --> 04:56.910
podem ocorrer erros.

04:56.910 --> 04:59.730
Esses sistemas exigem o armazenamento em buffer ou o registro

04:59.730 --> 05:01.350
dos dados para reduzir a carga elétrica

05:01.350 --> 05:02.370
usada por esses sistemas

05:02.370 --> 05:04.680
que têm grandes quantidades de módulos de memória,

05:04.680 --> 05:06.450
e isso pode ser combinado com paridade ou

05:06.450 --> 05:08.220
memória de código de correção de erros para

05:08.220 --> 05:10.140
oferecer a confiabilidade adicional que

05:10.140 --> 05:13.020
você está procurando e detectar esses erros.

05:13.020 --> 05:15.510
Agora, para usar os módulos de código de correção de

05:15.510 --> 05:18.840
erros, a placa-mãe deve ser compatível com eles, assim como a CPU.

05:18.840 --> 05:21.450
Se um desses componentes não for compatível

05:21.450 --> 05:24.450
com ECC, mesmo que você compre os módulos ECC, que custam

05:24.450 --> 05:27.150
mais, não terá o benefício extra do ECC.

05:27.150 --> 05:28.800
Portanto, tenha isso em mente.

05:28.800 --> 05:32.700
Além disso, a maioria das placas-mãe é compatível com ECC ou não.

05:32.700 --> 05:34.140
Geralmente, essa não é uma opção.

05:34.140 --> 05:36.690
Portanto, se você comprar uma placa-mãe que suporte

05:36.690 --> 05:38.940
ECC, terá que comprar módulos ECC, que são

05:38.940 --> 05:41.490
os módulos de memória registrados.

05:41.490 --> 05:44.160
Agora, se você encontrar uma placa-mãe que suporte

05:44.160 --> 05:46.170
módulos ECC ou não ECC, geralmente

05:46.170 --> 05:49.110
ela não suportará ambos ao mesmo tempo.

05:49.110 --> 05:51.570
Portanto, todos os seus módulos precisam

05:51.570 --> 05:53.880
ser ECC ou nenhum deles pode ser ECC.

05:53.880 --> 05:56.700
Ter uma mistura deles pode causar erros no sistema e a

05:56.700 --> 05:58.950
placa-mãe não saberá como lidar com isso.

05:58.950 --> 06:00.210
Agora, a última coisa que

06:00.210 --> 06:02.370
quero mencionar é que, se você estiver usando

06:02.370 --> 06:04.710
DDR5, a DDR5 tem alguma verificação de erros

06:04.710 --> 06:06.780
interna nos próprios módulos.

06:06.780 --> 06:10.500
Isso não é considerado ECC ou um módulo ECC.

06:10.500 --> 06:11.850
Portanto, essa correção de

06:11.850 --> 06:14.520
erros dentro dos módulos DDR5 mais novos pode ser usada

06:14.520 --> 06:17.160
em placas-mãe que não suportam ECC e você ainda terá

06:17.160 --> 06:19.710
algum recurso de verificação de erros.

06:19.710 --> 06:21.420
Essa é uma forma diferente de verificação

06:21.420 --> 06:23.910
de erros e não é considerada um código de correção de erros.

06:23.910 --> 06:26.250
Portanto, tenha isso em mente e não deixe que isso o confunda

06:26.250 --> 06:27.810
quando estiver em campo.

06:27.810 --> 06:29.640
Essa é uma forma diferente de verificação

06:29.640 --> 06:32.040
de erros e os módulos DDR5 ainda podem ser vendidos

06:32.040 --> 06:34.740
como módulos ECC ou não ECC, pois, além dessa verificação

06:34.740 --> 06:37.290
interna de erros, eles também podem trabalhar

06:37.290 --> 06:39.840
com a CPU e a placa-mãe se elas suportarem ECC e

06:39.840 --> 06:41.580
agora também são códigos de correção

06:41.580 --> 06:44.040
de erros.

06:44.040 --> 06:45.510
Sei que isso pode ser um pouco confuso.

06:45.510 --> 06:48.210
Portanto, fique atento a isso quando estiver em campo.