Cytowany artykuł CMU-Intel pokazuje (na stronie 5), że poziom błędu zależy w dużej mierze od numeru części / daty produkcji modułu DRAM i zmienia się 10-krotnie. Istnieją również pewne oznaki, że problem jest znacznie mniej wyraźny w ostatnio produkowanych układach scalonych (2014).
Przytoczona liczba „9,4x10 ^ -14” została użyta w kontekście proponowanego teoretycznego mechanizmu łagodzenia o nazwie „PARA” (który może być podobny do istniejącego mechanizmu łagodzenia pTRR (pseudo Odśwież wiersz docelowy)) i nie ma znaczenia dla twojego pytanie, ponieważ PARA nie ma nic wspólnego z ECC.
Drugi artykuł CMU-Intel (strona 10) wspomina o wpływie różnych algorytmów ECC na redukcję błędów (współczynnik 10 ^ 2 do 10 ^ 5, być może znacznie więcej przy wyrafinowanych testach pamięci i „zabezpieczaniu”).
ECC skutecznie zamienia exploit Row Hammer w atak DOS. Błędy 1bit zostaną skorygowane przez ECC, a gdy tylko zostanie wykryty niemożliwy do skorygowania błąd 2bit, system zatrzyma się (zakładając SECDED ECC).
Rozwiązaniem jest zakup sprzętu obsługującego pTRR lub TRR. Zobacz aktualny wpis na blogu Cisco o Row Hammer . Przynajmniej niektórzy producenci wydają się mieć jeden z tych mechanizmów ograniczających ryzyko wbudowanych w swoje moduły DRAM, ale trzymają go głęboko ukryty w swoich specyfikacjach. Aby odpowiedzieć na twoje pytanie: zapytaj sprzedawcę.
Szybsze odświeżanie (32 ms zamiast 64 ms) i agresywne interwały Patrol Scrub również pomagają, ale miałyby wpływ na wydajność. Ale nie znam żadnego sprzętu serwerowego, który faktycznie umożliwia precyzyjne dostrojenie tych parametrów.
Wydaje mi się, że niewiele można zrobić po stronie systemu operacyjnego, oprócz kończenia podejrzanych procesów przy stałym wysokim zużyciu procesora i dużym braku pamięci podręcznej.