| Data: 2020-10-09 19:25:14 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-09, pioruns <www@website.com> wrote:
Witajcie, Na stronie Asusa podają, że obsługuje, przy czym na dostępnej tam liście pamięci obsługiwanych jest wymieniona tylko jedna ECC. Jest to jedna z 2ch pamięci Transcend'a w tym zestawieniu i co ciekawe, druga jest identyczna, a figuruje jako zwykła. Ale na Reddicie są raporty, że obsługuje i inne. Dodatkowo, tu: https://www.reddit.com/r/AMDHelp/comments/8w5ftu/which_ram_for_asus_prime_b350plus_using_ryzen_7/e1tifry/ ktoś twierdzi, że większość niebuforowaych ecc powinna działać. No więc widać, że obsługuje, tylko niekoniecznie każdą. Szukałbym po konkretnej pamięci. -- Marcin |
|
| Data: 2020-10-11 23:44:11 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 09/10/2020 20:25, Marcin Debowski wrote:
Na stronie Asusa podają, że obsługuje, przy czym na dostępnej tam liście pamięci obsługiwanych jest wymieniona tylko jedna ECC. Jest to jedna z 2ch pamięci Transcend'a w tym zestawieniu i co ciekawe, druga jest identyczna, a figuruje jako zwykła. Ale na Reddicie są raporty, że obsługuje i inne.Dzięki za odpowiedź. Tak sobie szukam i bardzo mało jest Unbuffered ECC DDR4 w porównaniu do Registered ECC. Ponadto, płyta obsługuje max 16GB per stick. Obecnie mam tam takie: https://www.corsair.com/us/en/Categories/Products/Memory/VENGEANCE-LPX/p/CMK32GX4M4A2400C16#tab-tech-specs 2400MHz @ CAS 16 Unbuffered non-ECC. Czytam dalej w necie, że pamięć gubi desktopowa non-ECC gubi zazwyczaj 1 bit na miesiąc na 1 GB RAM. A więc ja gubię 4 bajty na miesiąc :/ Nic dziwnego, że dostałem data corruption na dysku po wielu miesiącach uptime - w sumie po roku pracy z resetami oczywiście. Wykrył mi je program (bo się wywalał na swoich własnych plikach), a sprawę nagłośnił Btrfs w dmesg. Przejechałem dyski btrfs scub (checksum corruption wykryte w jednym pliku, nic więcej). Sformatowałem dyski od nowa, zmigrowałem z mdadm raid1 do natywnego btrfs raid1. Zero błędów nośnika po formacie i po scrubie. Przejechałem oba Spinritem. Nic. SMART Extended Self Test nic. Zero bad sektorów i w ogóle. A więc pamięć :| Znalazłem te dwie: https://www.scan.co.uk/products/16gb-1x16gb-samsung-m391a2k43bb1-ctd-ddr4-workstation-ram-pc4-21300-2666-ecc-unbuffered-cas-19-dual https://www.scan.co.uk/products/8gb-samsung-1x8-ddr4-pc4-21300-2666mhz-cl17-12v-ecc-udimm-server-memory Jak myślisz, nada się to? Obydwa są 2666MHz Unbuffered ECC no i Samsunga. Prędkość też fajna bo byłoby to upgrade z obecnego 2400MHz. Trochę gorsze CAS bo 16GB ma C19 a 8GB ma C17, ale ECC musi być. Inaczej będę musiał szukać innej płyty ;) Są jakieś płyty pod Ryzena, które idą z ECC Registered? -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-13 23:26:17 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-11, pioruns <www@website.com> wrote:
On 09/10/2020 20:25, Marcin Debowski wrote: Mimo wszystko to trochę dziwne bo gubienie RAM nie musi się przekładać od razu na dysk. Musi być jeszcze jakaś operacja dyskowa z tymi będnymi danymi. MZ tego się nie da prosto oszacować, ale wydawałoby się, że nie powinno być tego dużo, tj. jakiś ułamek błędów pochodnych RAM. No chyba, że te dyski przerzucają dane non-stop. resetami oczywiście. Wykrył mi je program (bo się wywalał na swoich Nie masz czegoś co może istotnie zakłócać, nie wiem, jakieś silne, zmienne pola EM, albo jakieś źródło promieniowania? :) Swoją drogę, te komunikaty o błędach (chksum) nie dotyczą braku "symetryczności" na obu pulach tego Raid 1? Inaczej mówiąc, czy ten Raid 1 naprawia indywidualne błędy zupełnie transparentnie, czy może ten błąd to własnie wynik niezgodności obu kopii? Znalazłem te dwie: Nie mogę tam wleźć, bo str. uważa, że ją atakuję :) A nie masz możliwość zakupu tech kości aby sprawdzić i jeśli nie działają, zwrócić? ECC są generalnie bardzo drogie. Chyba mimo wszystko próbowałbym to jakoś ogarnąć programowo. Nie wiem, zrobić automatyczne tworzenie plików par2 z bardzo niską redundancją (0.1-0.5%) z okresowym spradzaniem? -- Marcin |
|
| Data: 2020-10-14 14:09:46 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 14/10/2020 00:26, Marcin Debowski wrote:
Nie masz czegoś co może istotnie zakłócać, nie wiem, jakieś silne, zmienne pola EM, albo jakieś źródło promieniowania? :) Swoją drogę, te komunikaty o błędach (chksum) nie dotyczą braku "symetryczności" na obu pulach tego Raid 1? Inaczej mówiąc, czy ten Raid 1 naprawia indywidualne błędy zupełnie transparentnie, czy może ten błąd to własnie wynik niezgodności obu kopii? W PC jest oczywiście zasilacz PC a także obok, stykając się obudowami, jest UPS ze swoim zasilaczem. Czyli standardowe urządzenia komputerowe, które mają jakąś tam odporność na ESD. Znalazłem te dwie: Właśnie tak zrobiłem. Zakupiłem jedną kość 16GB 2666MHz DDR4 ECC CL19 DIMM marki Kingston Server Premier: https://www.ebuyer.com/834676-kingston-server-premier-ksm26ed8-16me-16gb-2666mhz-ddr4-ecc-cl19-dimm-ksm26ed8-16me Zobaczymy jak przyjdzie, czy działa :) ECC są generalnie bardzo drogie. Chyba mimo wszystko próbowałbym to jakoś ogarnąć programowo. Nie wiem, zrobić automatyczne tworzenie plików par2 z bardzo niską redundancją (0.1-0.5%) z okresowym spradzaniem? A możesz przybliżyć co masz na myśli z tworzeniem tych plików, dokładniej? Wyczerpały mi się pomysły, dlatego wziąłem się za pamięć ECC, bo serwer chodzi 24/7, to fakt. A dane odnośnie statystycznej ilości bitów uszkodzonych na miesiąc na 1 GB zwykłego RAM mnie powalił. Dalej myślę, czy to czasem nie dyski, czy kontroler czy coś. Przykładowo, jeden z dysków raportuje się tak: Model Family: Seagate Barracuda 3.5 Device Model: ST2000DM006-2DM164 Serial Number: Z4Z9VCVN LU WWN Device Id: 5 000c50 0a5def0ef Firmware Version: CC26 User Capacity: 2,000,398,934,016 bytes [2.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 7200 rpm Form Factor: 3.5 inches Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) ID# ATTRIBUTE_NAME: RAW_VALUE 1 Raw_Read_Error_Rate: 125205888 3 Spin_Up_Time: 0 4 Start_Stop_Count: 1276 5 Reallocated_Sector_Ct: 0 7 Seek_Error_Rate: 1829851896660 9 Power_On_Hours: 14599 10 Spin_Retry_Count: 0 12 Power_Cycle_Count: 680 183 Runtime_Bad_Block: 1 184 End-to-End_Error: 0 187 Reported_Uncorrect: 0 188 Command_Timeout: 0 189 High_Fly_Writes: 130 190 Airflow_Temperature_Cel: 29 191 G-Sense_Error_Rate: 0 192 Power-Off_Retract_Count: 16 193 Load_Cycle_Count: 147909 194 Temperature_Celsius: 29 197 Current_Pending_Sector: 0 198 Offline_Uncorrectable: 0 199 UDMA_CRC_Error_Count: 3 240 Head_Flying_Hours: 11119h+37m+20.737s 241 Total_LBAs_Written: 226553923475 242 Total_LBAs_Read: 464637728080 Jest to jeden z gorszych dysków, drugi ma lepsze staty. Ten miał 3 błędy checksum na kablu (drugi miał 1), a więc kable chyba spoko. 0 realokacji czy oczekujących sektorów, 0 command timeout (to dobrze, bo nigdy nie wywaliły requestu systemu o jakiś sektor), ale 1 "runtime_bad_block". Wszelkie testy Read-InvertWrite-Verify-InvertWrite-Read-Verify (czyli Spinrite level 4), scruby btrfsem przechodzą te dyski 100% idealnie w tym momencie, wszystkie SMART self testy też. Dyski bardzo dużo piszą i czytają, bo mam przeróżne usługi na tym serwerze włącznie ze swapem i całym /home i /var (a więc /var/www i /var/cache, /var/log też, a tam w nich duża mielonka jest). Nie wiem jak czytać "Total_LBAs_Written" i "Total_LBAs_Read", ale jeśli przyjąć, że LBA to 512 bajtów, to dyski zapisują 36 TB na rok i czytają 283 TB na rok, po przeliczeniu ile pracowały. A mają po 2 TB pojemności. Gdyby to były SSD to już by się dawno zajechały, mam wrażenie :) -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-14 14:13:06 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 14/10/2020 14:09, pioruns wrote:
9 Power_On_Hours: 14599 Licząc ile TB zapisują i odczytują na rok wziąłem błędnie pod uwagę Head Flying Hours (czyli czas kiedy były aktywne głowice jak rozumiem). Ale wychodzi na to, że większość czasu i tak były akywne, a więc dysk cały czas coś mieli. Dyski żyją online 608 dni, a głowice pracowały 463 dni, a więc 3/4 czasu. -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-16 00:17:41 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 maks temperatura | |
|
Podepne się z jednym pytaniem, bo połowa jest sprzętowo w temacie. Jest coś dziwnego z tym cpu jeśli chodzi o dane dotyczące maks. temperatury. Google, praktycznie jednomyślnie podaje 75C. Większość ze stron, które tak podają jest z okolic 2017. Natomiast na str. AMD stoi jak wół, że 95C. O co tu chodzi? Są jakieś różne wersje tego cpu, które się tak drastycznie różnią, czy też AMD się wczesniej zabezpieczał?
-- Marcin |
|
| Data: 2020-10-16 12:39:45 | |
| Autor: pioruns | |
| Ryzen 7 1700 maks temperatura | |
|
On 16/10/2020 01:17, Marcin Debowski wrote:
Podepne się z jednym pytaniem, bo połowa jest sprzętowo w temacie. Jest coś dziwnego z tym cpu jeśli chodzi o dane dotyczące maks. temperatury. Google, praktycznie jednomyślnie podaje 75C. Większość ze stron, które tak podają jest z okolic 2017. Natomiast na str. AMD stoi jak wół, że 95C. O co tu chodzi? Są jakieś różne wersje tego cpu, które się tak drastycznie różnią, czy też AMD się wczesniej zabezpieczał?Różnica 20 C wynika z offsetu +20 C, który nadal AMD sensorom tCTL w tych procesorach. Czyli, podają one o 20C gorętszą temperaturę niż jest w rzeczywistości. Wyjaśnienie: https://www.guru3d.com/news-story/amd-ryzen-7-have-a-temperature-20-degree-c-reporting-offset.html Niektóre narzędzia dla Windows podają temperaturą jaką serwuje procesor (błędną, wyższą o 20C), a niektóre już przeliczają z offsetem i podają prawidłową, fizyczną temperaturę, niższą o 20C. Dlatego też potem wyniki na internecie się tak różnią. Odpal PC z stanu uśpienia (niech stoi parę godzin aby był zimny), miej już otwarte wszelakie narzędzia pomiarowe na ekranie, zobacz jakie są temperatury od zimnego. Na starcie powinno być 20C czy praktycznie tyle co temperatura otoczenia. W ten sposób znajdziesz narzędzia, które pokazują z offsetem i bez offsetu. -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-16 12:00:43 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 maks temperatura | |
|
On 2020-10-16, pioruns <www@website.com> wrote:
On 16/10/2020 01:17, Marcin Debowski wrote: Ale to jest temperatura bieząca a ja mówię o maksymalnej. Mam rozumiec, że niektórzy podają 75C z ofsetem? Swoją drogą seria FX nie informowała o temperaturze, ale był to ofset właśnie od T maks. Czy oni nie mogą się zdecydować na coś normalnego, albo przynajmniej być konsekwentni? Niektóre narzędzia dla Windows podają temperaturą jaką serwuje procesor Sprawdzam Asusowym do overclocking (AI Suite 3, płyta Prime X370-PRO, R7 1700 pro). Wydaje się podawać poprawnie. Tylko właśnie nie wiem jaki maks. Automatyczna optymalizacja doszła do 79C przy zabawie z zegarem i napięciami, więc w sumie wydaje się to wskazywać na 75C. Tylko, że to jest MZ temperatura rzeczywistą, więc dlaczego AMD podaje 95C? -- Marcin |
|
| Data: 2020-10-16 13:07:40 | |
| Autor: pioruns | |
| Ryzen 7 1700 maks temperatura | |
|
On 16/10/2020 13:00, Marcin Debowski wrote:
On 2020-10-16, pioruns <www@website.com> wrote: Heh, no tak, mój błąd! Powinienem na przykładzie temp. max. to opisać. Ale temp. max. ma taki sam offet jak temperatura aktualna.
Moja interpretacja: (zgaduję) Jak czytasz bezpośrednio z płyty głównej/BIOSu, to masz np. temperaturę aktualną 60C zamiast 40C, a maksymalną 95C zamiast 75C. Dystans do maksymalnej masz ten sam, co jakbyś użył narzędzia, które pokazuje 40C aktualną i 75C maksymalną (czyli prawdziwe temperatury fizyczne). Też mi się wydaje, że temp. max tych procesorów to 75C czyli (95C prosto z BIOSu). Odpal kompa z zimnego to się dowiesz co ten AI Suite 3 pokazuje tak naprawdę. Wydaje mi się, że cały ten cyrk jest zrobiony po to, aby ludziom się nie paliły procki, procek który mówi, że jest 20C gorętszy niż jest w rzeczywistości włączy sobie throttling szybciej i się nie zniszczy. -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-17 01:34:41 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 maks temperatura | |
|
On 2020-10-16, pioruns <www@website.com> wrote:
On 16/10/2020 13:00, Marcin Debowski wrote: Bios wydaje się pokazywac poprawną - zwykle ca 38-49C (dla przypomnienia, u mnie RT to 30-35C, MB >=35C). Odpal kompa z zimnego to się dowiesz co ten AI Suite 3 pokazuje tak No ale mamy sytuację w sumie odwrotną. Obecnie AMD twierdzi max 95C a Redity i różne strony ze spec. 75C. Czyli tak jakby AMD zachęcał, śmiało, do 95C jest jeszcze sporo :) -- Marcin |
|
| Data: 2020-10-16 13:12:12 | |
| Autor: pioruns | |
| Ryzen 7 1700 maks temperatura | |
|
On 16/10/2020 13:00, Marcin Debowski wrote:
Sprawdzam Asusowym do overclocking (AI Suite 3, płyta Prime X370-PRO, R7 1700 pro). Wydaje się podawać poprawnie. Tylko właśnie nie wiem jaki maks. Automatyczna optymalizacja doszła do 79C przy zabawie z zegarem i napięciami, więc w sumie wydaje się to wskazywać na 75C. Tylko, że to jest MZ temperatura rzeczywistą, więc dlaczego AMD podaje 95C? Ja mam bardzo łatwo, bo Linux mi pokazuje prawdziwą fizyczną temperaturę w narzędziu lm-sensors. Np. serwer aktualnie 35 C (Ryzen 7 1700 TDP 65W) a desktop 47 C (Ryzen 5 1600X TDP 95W). Nie ma opcji, że wyświetla z offsetem, bo wtedy serwer miałby 15 C co jest niemożliwe :) Przełącz się na chwilę do Ubuntu liveCD to też możesz zobaczyć prawdziwą temperaturę bez wątpliwości. -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-17 01:29:13 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 maks temperatura | |
|
On 2020-10-16, pioruns <www@website.com> wrote:
On 16/10/2020 13:00, Marcin Debowski wrote: Ja jestem linuksiarz, problem w tym że lm_sensors nie zawsze pokazuje poprawnie bez ręcznego grzebania w konfiguracji. Moje zainteresowanie temperaturą występuje zaś w okolicach fizycznego złożenia sprzętu i nie chciałbym spędzac wielu godzin babrząc się w tym, stąd założenie, że windowsowski program dołączony do sprzętu jednak powinien to pokazywać poprawnie bez większych cyrków. Poza tym np. dla płyty, którą mam pod R5 3600 (PRIME B350M-E), sensors-detect pokazuje to: Driver `k10temp' (autoloaded): * Chip `AMD Family 17h thermal sensors' (confidence: 9) Driver `to-be-written': * ISA bus, address 0x290 Chip `ITE IT8655E Super IO Sensors' (confidence: 9) A sensors to: nouveau-pci-0900 Adapter: PCI adapter fan1: 1032 RPM temp1: +35.0°C (high = +95.0°C, hyst = +3.0°C) (crit = +105.0°C, hyst = +5.0°C) (emerg = +135.0°C, hyst = +5.0°C) k10temp-pci-00c3 Adapter: PCI adapter Tdie: +35.5°C (high = +70.0°C) Tctl: +35.5°C Powyższe dla k10temp-pci-00c3, to jest temp. cpu ale to nie jest poprawna temperatura. Jest zaniżona właśnie o około 20C. -- Marcin |
|
| Data: 2020-10-16 00:10:16 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-14, pioruns <www@website.com> wrote:
On 14/10/2020 00:26, Marcin Debowski wrote: Też jestem ciekaw :) ECC są generalnie bardzo drogie. Chyba mimo wszystko próbowałbym to jakoś ogarnąć programowo. Nie wiem, zrobić automatyczne tworzenie plików par2 z bardzo niską redundancją (0.1-0.5%) z okresowym spradzaniem? Jakiś skrypt, który skanuje dyski, jeśli znajdzie nowy plik to zapuszcza par2 i robi plik korekcyjny. Wczesniej oczywiście sprawdza czy ten już nie istnieje. Jak potem stwierdzisz uszkodzenie to będzie łatwo odtworzyć. Miejsca przy niskiej redundancji tez to nie zajmie. Wyczerpały mi się pomysły, dlatego wziąłem się za pamięć ECC, bo serwer E, chyba się zgubiłem, to powyższe nie wygląda jak prawie padły dysk? Moja 1TB Toshiba 2.5" z 2x dłuższym godzinowo przebiegiem ma tu 2x 0. Też pracuje w serwerze 24/7, ram zwykły. 9 Power_On_Hours: 14599 Nie wiem jak czytać "Total_LBAs_Written" i "Total_LBAs_Read", ale jeśli Przyjmując rozmiar sektora 512 powyższe oznacza że w ciągu 14599h zapisano ca 100TB. Wychodzi ca 2.1MB/s. Przyjmując dalej, że nieuśredniona prędkość zapisu była w granicach 70MB/s, oznacza to, że w ciągu roku dysk zapisywał 12 dni więc te dane dla błędów RAMu należałoby przemnożyć przez 12 i podzielić przez 365. To tego jeszcze operacje dyskowe nie korzystają z pełnego RAM, a zapewne z jakiejś niewielkiej jego częsci, więc to się też tak nie przekłada, że czym masz więcej ramu, tym większe prawdopodobieństwo błędu na dysku a jest to raczej proporcjonalne do statystycznej zajętości RAMu przez jakiś dyskowy cache czy inny bufor wykorzystywany do zapisu. To są pewnie dziesiątki-setki MB niż GB, więc i prawdopodobieństwo, że dziabnie taki fragment jest pomniejszoneo dalszy rząd wielkości. Czyli przy 1bit/miesiac/1GB wychodzi mi pi x drzwi, ze powinieneś mieć z tego błędów na dysku w granicach 1 bit na 30 lat. -- Marcin |
|
| Data: 2020-10-16 12:33:43 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 16/10/2020 01:10, Marcin Debowski wrote:
Każdy producent inaczej pokazuje Error Rates. Niektóre dyski nieID# ATTRIBUTE_NAME: RAW_VALUEE, chyba się zgubiłem, to powyższe nie wygląda jak prawie padły dysk? pokazują tu nic, zero, a niektóre miliony korekcji, bo każdy kontroler co innego uznaje jako "błąd". -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-16 19:03:47 | |
| Autor: Olaf Frikiov Skiorvensen | |
| Ryzen 7 1700 + ECC RAM | |
|
Wcale nie przypadkiem, dnia Fri, 16 Oct 2020 12:33:43 +0100 doszła do mnie wiadomość <rmc0eo$9bt$1$pioruns@news.chmurka.net> od pioruns <www@website.com> :
On 16/10/2020 01:10, Marcin Debowski wrote: To pole może być połączeniem dwóch wartości, całkowita ilość pozycjonowań/całkowita ilość błędów pozycjonowania(w Seagate chyba tak jest), to samo może dotyczyć parametru Raw Error Rate i innych(całkowita ilość odczytów/całkowita ilość błędnych odczytów lub całkowita ilość odczytów/ilość błędnych odczytów od włączenia zasilania dysku, czyli po włączeniu zerowana była ilość błędów). W dokumentacji gdzieś to mieli, kiedyś była osiągalna na ich stronie www. -- Gdyby się wysadziło ich planety, zburzyło miasta, spaliło księgi, a ich samych wytłukło do nogi, może udałoby się ocalić naukę miłości bliźniego. SL. |
|
| Data: 2020-10-17 01:08:11 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-16, Olaf Frikiov Skiorvensen <Belzebub@invalid.invalid> wrote:
Wcale nie przypadkiem, dnia Fri, 16 Oct 2020 12:33:43 +0100 doszła do mnie wiadomość <rmc0eo$9bt$1$pioruns@news.chmurka.net> od pioruns <www@website.com> : No właśnie sprawdziłem omalże dziewiczego Seagata i też to ma. Internety twierdzą, że należy się niepokoić. Smartctl mówi pre-fail: 1 Raw_Read_Error_Rate [..] Pre-fail Always - 72695726 7 Seek_Error_Rate [..] Pre-fail Always - 21614701 (ST8000DM004-2CX188) Czyli nalezy rozumieć że takie błędy to norma? -- Marcin |
|
| Data: 2020-10-17 03:22:54 | |
| Autor: Olaf Frikiov Skiorvensen | |
| Ryzen 7 1700 + ECC RAM | |
|
Wcale nie przypadkiem, dnia Sat, 17 Oct 2020 01:08:11 GMT doszła do mnie wiadomość <%triH.630911$jbb.526219@fx44.ams1> od Marcin Debowski <agatek@INVALID.zoho.com> :
On 2020-10-16, Olaf Frikiov Skiorvensen <Belzebub@invalid.invalid> wrote: Nie mogę odgrzebać pdf-a od seagate, ale znalazłem coś, co się zgadza z tym, co pamiętam. Tak jak mówiłem: http://www.users.on.net/~fzabkar/HDD/Seagate_SER_RRER_HEC.html Seek Error Rate The raw value of each SMART attribute occupies 48 bits. Seagate's Seek Error Rate attribute consists of two parts -- a 16-bit count of seek errors in the uppermost 4 nibbles, and a 32-bit count of seeks in the lowermost 8 nibbles. In order to see these data, we will need a SMART utility that reports all 48 bits, preferably in hexadecimal. Two such utilities are HD Sentinel and HDDScan. Wystarczy odczytać parametry SMART w HEX, i będzie to widać. To dotyczy też innych parametrów typu "error rate". -- Gdyby się wysadziło ich planety, zburzyło miasta, spaliło księgi, a ich samych wytłukło do nogi, może udałoby się ocalić naukę miłości bliźniego. SL. |
|
| Data: 2020-10-17 04:06:17 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-17, Olaf Frikiov Skiorvensen <Belzebub@invalid.invalid> wrote:
Wcale nie przypadkiem, dnia Sat, 17 Oct 2020 01:08:11 GMT Dzięki Olaf, czyli tak, to moje powyżej (dec)72695726 (hex)149D09D. Uppermost 4 (z 12) nibbles to 0, czyli należy to odczytać, że mamy 0 błędów/72695726 odczytów. Podobnie z "seek". Miło. Czyli na szybko, bez przeliczania błędy są jeśli przy Seagatach te dwa pola mają wartości dec 4294967297 lub więcej. U pioruna: 1 Raw_Read_Error_Rate: 125205888Nie ma błędów. 7 Seek_Error_Rate: 1829851896660Są błędy. -- Marcin |
|
| Data: 2020-10-17 11:21:17 | |
| Autor: Olaf Frikiov Skiorvensen | |
| Ryzen 7 1700 + ECC RAM | |
|
Wcale nie przypadkiem, dnia Sat, 17 Oct 2020 04:06:17 GMT doszła do mnie wiadomość <Z4uiH.898637$dTb.324643@fx41.ams1> od Marcin Debowski <agatek@INVALID.zoho.com> :
On 2020-10-17, Olaf Frikiov Skiorvensen <Belzebub@invalid.invalid> wrote: http://www.users.on.net/~fzabkar/HDD/Seagate_SER_RRER_HEC.html Błędy seek error mogą wynikać z trzęsionki dysku(coś nim szarpie, drugi dysk obok, stary wentylator czy trzęsienie ziemi). Przykładowo, odpalić skan dysku w Victorii czy MHDD, włączyć widok "grid" i lekko stukać palcem w skanowany dysk czy w cały komputer(tu trochę mocniej). Rezultaty mogą cię zaskoczyć(nowsze dyski jakoś dają sobie z tym radę, starsze szaleją). -- Gdyby się wysadziło ich planety, zburzyło miasta, spaliło księgi, a ich samych wytłukło do nogi, może udałoby się ocalić naukę miłości bliźniego. SL. |
|
| Data: 2020-10-17 10:24:51 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 17/10/2020 10:21, Olaf Frikiov Skiorvensen wrote:
Błędy seek error mogą wynikać z trzęsionki dysku(coś nim szarpie, drugi dysk obok, stary Pamiętajcie też aby nie krzyczeć na swoje dyski :D https://www.youtube.com/watch?v=tDacjrSCeq4 Hahaha -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-17 10:01:48 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-17, pioruns <www@website.com> wrote:
On 17/10/2020 10:21, Olaf Frikiov Skiorvensen wrote: No więc widzisz, że to nie musi być RAM. Sam staram się nie wychodzić poza "ty niedobry dysku", wszystko przytłumionym głosem i tylko jak się zamknę w kiblu, a i tak wczoraj miałem jeden unrecoverable we wcześniej wspomnianej macierzy. A jak któryś przegnie, to warto podrzucić na niego kopię tego: https://arstechnica.com/information-technology/2018/05/attackers-can-send-sounds-to-ddos-video-recorders-and-pcs/ -- Marcin |
|
| Data: 2020-10-17 12:52:56 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 17/10/2020 11:01, Marcin Debowski wrote:
A jak któryś przegnie, to warto podrzucić na niego kopię tego: Mój serwer na szczęście nie ma głośników :D -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-17 03:39:45 | |
| Autor: Olaf Frikiov Skiorvensen | |
| Ryzen 7 1700 + ECC RAM | |
|
Wcale nie przypadkiem, dnia Sat, 17 Oct 2020 01:08:11 GMT doszła do mnie wiadomość <%triH.630911$jbb.526219@fx44.ams1> od Marcin Debowski <agatek@INVALID.zoho.com> :
No właśnie sprawdziłem omalże dziewiczego Seagata i też to ma. Internety twierdzą, że należy się niepokoić. Smartctl mówi pre-fail: Przypomniało mi się co można zrobić, kiedy zawiodą wszystkie typowe metody odzyskiwania danych z HDD, ano to: https://www.kuvaton.com/browse/64240/01010101000111.jpg -- Gdyby się wysadziło ich planety, zburzyło miasta, spaliło księgi, a ich samych wytłukło do nogi, może udałoby się ocalić naukę miłości bliźniego. SL. |
|
| Data: 2020-10-17 01:57:25 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-17, Olaf Frikiov Skiorvensen <Belzebub@invalid.invalid> wrote:
Wcale nie przypadkiem, dnia Sat, 17 Oct 2020 01:08:11 GMT doszła do mnie wiadomość <%triH.630911$jbb.526219@fx44.ams1> od Marcin Debowski <agatek@INVALID.zoho.com> : Fejk. Tak się nie da odczytać. Nalezy wczesniej posypać opiłkami. -- Marcin |
|
| Data: 2020-10-16 12:46:34 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 16/10/2020 01:10, Marcin Debowski wrote:
Właśnie tak zrobiłem. Zakupiłem jedną kość 16GB 2666MHz DDR4 ECC CL19 Kostka 16GB dzisiaj przyszła. Będę testował, najpierw w desktopie (też AM4 + Ryzen), a potem w serwerze :) ECC są generalnie bardzo drogie. Chyba mimo wszystko próbowałbym to jakoś ogarnąć programowo. Nie wiem, zrobić automatyczne tworzenie plików par2 z bardzo niską redundancją (0.1-0.5%) z okresowym spradzaniem? Fajne narzędzie ten parchive, obczaję :) Przyda się do backupów może. Ale, Btrfs nie robi czegoś podobnego domyślnie? On porównuje zapisy na obu dyskach w swoim "raid1" i patrzy, czy wszystkie pliki są poprawnie zapisane. Robi to cały czas. Potrafi odtworzyć plik gdy dane zostaną uszkodzone, a także pracować z jednym dyskiem z zdegradowanym raidem. Nie zastąpi to danych nadmiarowych jak w WinRAR czy parchive, czy macierzy RAID6, ale spójność danych trzyma. Ma jednak trochę różnic od mdadm. Używam obydwu mdadm i btrfs w trybie RAID1. -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-17 01:55:06 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-16, pioruns <www@website.com> wrote:
On 16/10/2020 01:10, Marcin Debowski wrote: Na pewno nie ma takiej programowalnej redundacji. Używam par2 od czasu jak bardzo dziwnie posypał mi się duży Raid5. Tzn. wszystko było na poziomie logicznym ok, ale pliki miały uszkodzenia. A wracając do btrfs, u mnie jest o tyle gorzej, że chodzi mi to w układzie data:single, metadata:raid1 na 5 fizycznych dyskach. Dla takiego układu nie mogę znaleźć odpowiedzi na pytanie, czy wypadnięcie jednego fizycznego urządzenia umożliwi odtworzenie plików (po dodaniu sprawnego urządzenia) z pozostałych. Wydawałoby się, że ten raid 1 dla meta data powinien mieć kopie na różnych fizycznych urządzeniach, więc odpowiedź powinna brzmieć - tak, ale jak góglam, to widzę odpowiedzi na nie. -- Marcin |
|
| Data: 2020-10-17 10:20:38 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 17/10/2020 02:55, Marcin Debowski wrote:
A wracając do btrfs, u mnie jest o tyle gorzej, że chodzi mi to w układzie data:single, metadata:raid1 na 5 fizycznych dyskach. Dla takiego układu nie mogę znaleźć odpowiedzi na pytanie, czy wypadnięcie jednego fizycznego urządzenia umożliwi odtworzenie plików (po dodaniu sprawnego urządzenia) z pozostałych. Wydawałoby się, że ten raid 1 dla meta data powinien mieć kopie na różnych fizycznych urządzeniach, więc odpowiedź powinna brzmieć - tak, ale jak góglam, to widzę odpowiedzi na nie. No u mnie łatwiej, bo mam data też w raid1: btrfs filesystem df /home Data, RAID1: total=598.00GiB, used=535.91GiB System, RAID1: total=32.00MiB, used=128.00KiB Metadata, RAID1: total=1.00GiB, used=760.36MiB GlobalReserve, single: total=512.00MiB, used=0.00B Czytam po internetach, że jak mi wypadnie dysk to będę miał jeden raz możliwość zamontowania partycji w trybie degraded RW a potem już tylko Read. Taka przypadłość btrfs kiedyś była, nie wiem czy to nadal aktualne. mdadm jak testowałem partycję na root, to wyciągałem po dysku i sprawdzałem czy grub i system startuje i chodzi, i ładniej śmigał w degraded. Nie chce mi się teraz tego robić z btrfs, za duża partycja w razie czego gdybym musiał formatować i mielić od nowa :D -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-16 16:48:24 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
PamięćOn 16/10/2020 01:10, Marcin Debowski wrote:
Pamięć zainstalowana. Wygląda mi na pełny sukces!Zobaczymy jak przyjdzie, czy działa :) Dla przypomnienia, hardware: product: PRIME B350-PLUS product: AMD Ryzen 7 1700 Eight-Core Processor Dane z lshw: *-memory description: System Memory physical id: 26 slot: System board or motherboard size: 16GiB capabilities: ecc configuration: errordetection=multi-bit-ecc *-bank:1 description: DIMM DDR4 Synchronous Unbuffered (Unregistered) 2666 MHz (0.4 ns) product: 9965745-002.A00G vendor: Kingston physical id: 1 serial: 719CA3F9 slot: DIMM_A2 size: 16GiB width: 64 bits clock: 2666MHz (0.4ns) Dane z dmidecode: Handle 0x0026, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 128 GB Error Information Handle: 0x0025 Number Of Devices: 4 Handle 0x0027, DMI type 19, 31 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x003FFFFFFFF Range Size: 16 GB Physical Array Handle: 0x0026 Partition Width: 1 A więc wygląda na to, że Multi-Level ECC jest włączone :) Zajefajnie, bo tanio sprzęt dorwałem, używany, ale w stanie idealnym. Służy już ponad rok, dawno się zwrócił, a mam funkcjonalność i wydajność serwerów wielokrotnie droższych! Męczyłęm się z pół godziny chciałem zrobić tą pamięć niestabilną, nie chciała pokazać żadnych błędów w memtest86, a jak zlazłem z zegarami CAS/RAS etc za nisko to nie startowała, musiałem przepinać pamięć poprzednią spowrotem aby PC ruszył, i tak kilka razy aż w końcu dałem sobie spokój bo serwer ma chodzić. No i chodzi :) Teraz bede czekać na raporty błędów. edac-util mówi: mc0: 0 Uncorrected Errors with no DIMM info mc0: 0 Corrected Errors with no DIMM info mc0: csrow2: 0 Uncorrected Errors mc0: csrow2: mc#0csrow#2channel#1: 0 Corrected Errors mc0: csrow3: 0 Uncorrected Errors mc0: csrow3: mc#0csrow#3channel#1: 0 Corrected Errors edac-util: No errors to report. :D -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-17 01:14:01 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-16, pioruns <www@website.com> wrote:
PamięćOn 16/10/2020 01:10, Marcin Debowski wrote:[..] sobie spokój bo serwer ma chodzić. No i chodzi :) Teraz bede czekać na No to czejamy :) -- Marcin |
|
| Data: 2020-10-17 10:22:41 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 17/10/2020 02:14, Marcin Debowski wrote:
On 2020-10-16, pioruns <www@website.com> wrote: Dokupiłem 3 kostki, to będzie niedługo 64GB, jak przyjdą. Powinno pójść, bo cały wcześniejszy rok miałem tam 4x8 GB Corsair Vengeance LPX 2400 MT/s, a testowałem też 4x8 GB G.Skill 3200 MT/s, 64GB @ 2666 MT/s też powinno, tyle, że tym razem będzie z ECC. -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-19 03:56:19 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-17, pioruns <www@website.com> wrote:
On 17/10/2020 02:14, Marcin Debowski wrote: Swoją drogą, czy te ECC to jest specyfika lini B350 Asusa? Mam B350 MSI i nie ma słowa o ECC. Mam wspomniane gdzieindziej B350 Asusa, mATX i tez widze, że niby obsługuje ECC. -- Marcin |
|
| Data: 2020-10-19 12:35:41 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 19/10/2020 04:56, Marcin Debowski wrote:
Swoją drogą, czy te ECC to jest specyfika lini B350 Asusa? Mam B350 MSI i nie ma słowa o ECC. Mam wspomniane gdzieindziej B350 Asusa, mATX i tez widze, że niby obsługuje ECC. ASUS Prime B450 Plus ma dokładnie taki sam opis w specyfikacji, a więc pewnie też ECC obsługuje. A więc jest to ASUS, który robi dobrą robotę. Z kolei w mojej drugiej płycie Gigabite GA-AB350-Gaming 3 jest dokladnie napisane, że nie obsługuje: "Support for ECC Un-buffered DIMM 1Rx8/2Rx8 memory modules (operate in non-ECC mode)" No i ECC rzeczywiście wyłączyli, bo sprawdziłem, Linux raportuje brak ECC po włożeniu tej jednej kostki. -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-19 12:04:07 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-19, pioruns <www@website.com> wrote:
On 19/10/2020 04:56, Marcin Debowski wrote: No ale zobacz, X370 pro, która jest o klasę wyżej od B350 plus nie ma ECC. Z kolei w mojej drugiej płycie Gigabite GA-AB350-Gaming 3 jest dokladnie Ktoś zrobił ciekawy przegląd: https://www.kepstin.ca/blog/ryzen-motherboard-ecc-memory-summary/ -- Marcin |
|
| Data: 2020-10-19 13:46:24 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 19/10/2020 13:04, Marcin Debowski wrote:
No ale zobacz, X370 pro, która jest o klasę wyżej od B350 plus nie ma ECC. Specyfikacja mówi: "ECC Memory (ECC mode) support varies by CPU." Wszystkie ASUSy, które sprawdziłem mają ten sam wording w specyfikacji, A zajrzałem do PRIME B350, PRIME B450 i do tej. A więc skoro moja PRIME B350 ma działające ECC, to te dwie tez będą miały. -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-19 18:11:28 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-19, pioruns <www@website.com> wrote:
On 19/10/2020 13:04, Marcin Debowski wrote: Chipset AMD X370 Memory AMD Ryzen(TM) Processors 4 x DIMM, Max. 64GB, DDR4 3200(O.C.)/2933(O.C.)/2666/2400/2133 MHz Non-ECC, Un-buffered Memory AMD 7th Generation A-series/Athlon(TM) Processors 4 x DIMM, Max. 64GB, DDR4 2400/2133 MHz Non-ECC, Un-buffered Memory Dual Channel Memory Architecture * Refer to www.asus.com for the Memory QVL (Qualified Vendors Lists). Ale w Memory QVL jest wymieniony ten ECC Transcend'a od którego się dyskusja zaczeła. Coś chyba Asus dał informacyjnej dupy, no chyba, że jakaś dziwna polityka regionalizacyjna, lub to co wspomniano na tym blogu, do którego link wcześniej wkleiłem - że jest lub nie w zalezności od wersji płyty. -- Marcin |
|
| Data: 2020-10-19 19:55:36 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 19/10/2020 19:11, Marcin Debowski wrote:
On 2020-10-19, pioruns <www@website.com> wrote:Nie wiem skąd to bierzesz, ja biorę z oficjalnej specyfikacji płyty na stronie ASUS: https://www.asus.com/us/Motherboards/PRIME-X370-PRO/specifications/ I tam jest linijka, której w twojej wklejce nie ma: "Memory ECC Memory (ECC mode) support varies by CPU." PRIME B350 Plus i PRIME B450 Plus też tak mają. ASUS nie chwali się funkcjonalnością ECC i niezbyt dokładnie ją opisuje w specyfikacji, ale *działa*. Lepsze to, niż wycinanie/wyłączanie ECC/EDAC całkowicie w płycie tak jak robi to Gigabyte. -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-19 20:01:01 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-19, pioruns <www@website.com> wrote:
On 19/10/2020 19:11, Marcin Debowski wrote: https://www.asus.com/nz/Motherboards/PRIME-X370-PRO/specifications/ https://www.asus.com/sg/Motherboards/PRIME-X370-PRO/specifications/ https://www.asus.com/in/Motherboards/PRIME-X370-PRO/specifications/ https://www.asus.com/se/Motherboards/PRIME-X370-PRO/specifications/ https://www.asus.com/fi/Motherboards/PRIME-X370-PRO/specifications/ https://www.asus.com/de/Motherboards/PRIME-X370-PRO/specifications/ i pewnie parę tuzinów innych ASUS nie chwali się funkcjonalnością ECC i niezbyt dokładnie ją opisuje Jasne, ale dlaczgo gdzieniegdzie wręcz zaprzeczają? -- Marcin |
|
| Data: 2020-10-19 20:03:28 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-19, Marcin Debowski <agatek@INVALID.zoho.com> wrote:
https://www.asus.com/nz/Motherboards/PRIME-X370-PRO/specifications/ Te https://www.asus.com/se/Motherboards/PRIME-X370-PRO/specifications/ te oczywiscie nie :) -- Marcin |
|
| Data: 2020-10-19 22:32:02 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 19/10/2020 21:01, Marcin Debowski wrote:
https://www.asus.com/nz/Motherboards/PRIME-X370-PRO/specifications/ Masakra! Haha. ECC to aż tak niszowy feature, że poszczególne jednostki lokalne nie dbają o uaktualnianie danych w specyfikacji? :O Najważniejsze jednak, że ECC działa :) Na pewno jestem bardziej zadowolony z płyty kupionej za ?46 z eBay, niż z droższej Gigabyte, kupionej nowej, które ECC nie ma! -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-20 00:04:23 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-19, pioruns <www@website.com> wrote:
On 19/10/2020 21:01, Marcin Debowski wrote: Mając do wyboru Gigabyte i Asusa w podobnej cenie i funkcjonalnosci, Gigabyte bym nie wybrał. Asus był i nadal jest dobrą marką, choć myślę, że aż takich drastycznych różnic w jakości i trwałości może nie być, Ale też jak widać wychodza różne kwiatki. A jak wygląda cenowo Amazon UK (wnioskując po walucie)? Na amarykańskim, i moim podwórkowym (SG) bywają takie okazje, że czesto nie mogę zrozumieć o co w tym chodzi. Przykładowo, tę X370-pro kupiłem fabryczną nówkę, 3 tyg temu za taką cene, że Ci lepiej nie powiem, bo się możesz wkurzyć :) -- Marcin |
|
| Data: 2020-10-20 01:21:14 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 20/10/2020 01:04, Marcin Debowski wrote:
A jak wygląda cenowo Amazon UK (wnioskując po walucie)? Na amarykańskim, i moim podwórkowym (SG) bywają takie okazje, że czesto nie mogę zrozumieć o co w tym chodzi. Przykładowo, tę X370-pro kupiłem fabryczną nówkę, 3 tyg temu za taką cene, że Ci lepiej nie powiem, bo się możesz wkurzyć :) Jeśli wyrwałeś po dobrej cenie, to cieszę się :) Dawno nie miałem w rękach płyty AM4 z górnej półki... bo tak naprawdę nie potrzebuję żadnej z oferowanych przez nie funkcjonalności. Lepsze płyty dają lepszy overclocking, więcej prądu, więcej PCI-E lanes, Wifi czy inne blutoothy czy co tam jeszcze. Mi nic z tych rzeczy nie potrzeba, nie robię OC ani na serwerze (lol), ani na PC (używam Linuksa, gry raz w tygodniu, po co mi OC?). Za to topowe płyty biorą tyle prądu, że aż mają wiatraki na chipsecie. UPS serwera wyraża swój sprzeciw :D Amazon używam na przemian z całą gamą sklepów mainstreamowych. Najpeirw szukam produkt, który potrzebuję, potem przeglądam sklepy aż znajdę najlepszą ofertę. Nie mam czegoś takiego, że kupię w sklepie X bo tam zazwyczaj taniej, no to padnie na płytę Y bo ona najtańsza z AM4 w tym akurat sklepie. Może przez to przegapię jakieś tam amazonowe okazje, ale mam to, czego potrzebuję. Ale prawda, czasem Amazon ma jakieś fajne oferty czy promocje. Regularnie dostaję też vouchery do Amazonu z firmy, która robi surveys w mojej branży, za wypełnianie ankiet raz na miesiąc czy dwa, tak więc się uzbiera na fajną zniżkę co jakiś czas. -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-20 03:37:53 | |
| Autor: Marcin Debowski | |
| Ryzen 7 1700 + ECC RAM | |
|
On 2020-10-20, pioruns <www@website.com> wrote:
On 20/10/2020 01:04, Marcin Debowski wrote: Zasadniczo to potrzebowałem jakieś ATX z 3 pełnowymiarowymi PCI-E, żebym mógł poupychać dodatkowe karty z m.2. Uzywam zasadniczo do obróbki wideo. Wczesniejsza, też Asus pod FX-8350, zaczęła mieć problemy z dzwiękiem, ale pobujałem się na niej dodatkow z pół roku czekając na jakiś impuls aby przejść na AM4. Amazon używam na przemian z całą gamą sklepów mainstreamowych. Najpeirw No ale tak to nie działa, bo przeciez wstępną selekcję też na pewno robisz biorac pod uwagę cenę, więc finalnie jest to pewne optymum a nie wyłącznie minimum funkcjonalne dostosowane do potrzeb. Zresztą czesto można dostać coś ekstra za podobną cenę. Jakbyś, szukając tej swojej B350 zobaczył nówkę X370-pro to pewnie odżałowałbyś te ekstra 20 funtów :) Ale prawda, czasem Amazon ma jakieś fajne oferty czy promocje. Prawdę mówiąc, przy tych paru okazjach z jakich skorzystałem to Amazon był nie do przebicia. Cały impuls z przejściem na AM4 w sumie z tego wyszedł. -- Marcin |
|
| Data: 2020-10-20 09:58:43 | |
| Autor: JaceK | |
| Ryzen 7 1700 + ECC RAM | |
|
On 20.10.2020 02:21, pioruns wrote:
Jeśli wyrwałeś po dobrej cenie, to cieszę się :) Dawno nie miałem wTo jaka jest teraz pełna konfiguracja, na której pracujesz z obsługą ECC i Ryzenem? JaceK |
|
| Data: 2020-10-21 12:46:33 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 20/10/2020 08:58, JaceK wrote:
To jaka jest teraz pełna konfiguracja, na której pracujesz z obsługą ECC Ryzen 1700 + ASUS PRIME B350-PLUS + Kingston Server Premier (KSM26ED8/16ME) -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-20 10:40:39 | |
| Autor: JaceK | |
| Ryzen 7 1700 + ECC RAM | |
|
Jeśli wiesz jak przerobić moduł pamięci do testowania ECC to daj znać :)
https://forums.passmark.com/memtest86/4579-memtest86-ecc-ram-error-reporting-status |
|
| Data: 2020-10-21 12:45:33 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 20/10/2020 09:40, JaceK wrote:
Jeśli wiesz jak przerobić moduł pamięci do testowania ECC to daj znać :)Hehe ciekawe. Niestety nie mój level, mogę co najwyżej kable polutować :D -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|
| Data: 2020-10-23 00:47:01 | |
| Autor: pioruns | |
| Ryzen 7 1700 + ECC RAM | |
|
On 16/10/2020 01:10, Marcin Debowski wrote:
64GB w 4 kostkach zainstalowane :) # dmesg |grep EDAC [Fri Oct 23 00:13:28 2020] EDAC MC: Ver: 3.0.0 [Fri Oct 23 00:13:32 2020] EDAC amd64: F17h detected (node 0). [Fri Oct 23 00:13:32 2020] EDAC amd64: Node 0: DRAM ECC enabled. [Fri Oct 23 00:13:32 2020] EDAC amd64: MCT channel count: 2 [Fri Oct 23 00:13:32 2020] EDAC MC0: Giving out device to module amd64_edac controller F17h: DEV 0000:00:18.3 (INTERRUPT) [Fri Oct 23 00:13:32 2020] EDAC MC: UMC0 chip selects: [Fri Oct 23 00:13:32 2020] EDAC amd64: MC: 0: 8192MB 1: 8192MB [Fri Oct 23 00:13:32 2020] EDAC amd64: MC: 2: 8192MB 3: 8192MB [Fri Oct 23 00:13:32 2020] EDAC MC: UMC1 chip selects: [Fri Oct 23 00:13:32 2020] EDAC amd64: MC: 0: 8192MB 1: 8192MB [Fri Oct 23 00:13:32 2020] EDAC amd64: MC: 2: 8192MB 3: 8192MB [Fri Oct 23 00:13:32 2020] EDAC amd64: using x8 syndromes. [Fri Oct 23 00:13:32 2020] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED) [Fri Oct 23 00:13:32 2020] AMD64 EDAC driver v3.5.0 # edac-util -vs edac-util: EDAC drivers are loaded. 1 MC detected: mc0:F17h # edac-ctl -- mainboard edac-ctl: mainboard: ASUSTeK COMPUTER INC. PRIME B350-PLUS # dmidecode -t 16 # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x0026, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 128 GB Error Information Handle: 0x0025 Number Of Devices: 4 -- pozdrawiam, pioruns _,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,. Registered Linux User #454644 |
|