Köpråd sökes för dator med ECC ram

Permalänk
Medlem

Köpråd sökes för dator med ECC ram

Hej

Ska helst innan årsskiftet köpa in fem kompletta maskiner med stöd för ECC RAM, 32GB eller 64GB. Förr i tiden var det vanligt att AMD hade stöd för ECC, har det på en FX-6100 som nu ska ersättas, men nu verkar det vara tvärtom att det är Intel som har ECC stöd men inte AMD? Är tyvärr rätt lost på vad som gäller nu för tiden, maskinerna som de ska ersätta är nämnda FX-6100 samt fyra Intel 4770 system, dock utan ECC.

I och med att det handlar om fem system så får det gärna vara rimlig prissättning på det hela, men också fördel om det är förhållandevis energisnålt. Inbyggd grafikdel har jag också lärt mig att uppskatta de få sekunder jag behövt det.

Det jag behöver tips om är:

  • Prisvärd cpu

  • Prisvärt ECC minne

  • Prisvärt moderkort (som hanterar ECC)

Tack på förhand

Permalänk
Medlem

Amd med socker am4 stödjer ECC minnen, dubbelkolla bara att cpun stöder det.
Tror det bara är pro varianter som stöder det om du ska ha inbyggt grafik, om du inte tittar på 7000 serien.

Permalänk
Medlem

Aha, har väl egentligen bara tittat på 5-serien. Duger bra och är väl egentligen ett rätt stort prestandalyft som det är. Får läsa vidare!

Permalänk
Medlem
Skrivet av MsSmith:

Hej

Ska helst innan årsskiftet köpa in fem kompletta maskiner med stöd för ECC RAM, 32GB eller 64GB. Förr i tiden var det vanligt att AMD hade stöd för ECC, har det på en FX-6100 som nu ska ersättas, men nu verkar det vara tvärtom att det är Intel som har ECC stöd men inte AMD? Är tyvärr rätt lost på vad som gäller nu för tiden, maskinerna som de ska ersätta är nämnda FX-6100 samt fyra Intel 4770 system, dock utan ECC.

I och med att det handlar om fem system så får det gärna vara rimlig prissättning på det hela, men också fördel om det är förhållandevis energisnålt. Inbyggd grafikdel har jag också lärt mig att uppskatta de få sekunder jag behövt det.

Det jag behöver tips om är:

  • Prisvärd cpu

  • Prisvärt ECC minne

  • Prisvärt moderkort (som hanterar ECC)

Tack på förhand

Det duger inte med DDR5?
https://www.sweclockers.com/forum/trad/1637025-ddr5-har-ej-ri...

Visa signatur

*5600|B350M-A|16GB|GTX980Ti|GX750W|Core V21|280AIO|1TB+500GB.

AMD Ryzen 5(Zen3) @4891|Asus Prime|Corsair 2x8 LPX3000C15 @3200C16|Nvidia Geforce |Seasonic Focus| Thermaltake mATX kub|Arctic freezer II| NVMe SSD PCIE 3.0x2 Kingston A1000 1500/1000 + 2,5" HDD Western Digital Black Scorpio.

Permalänk
Medlem

känns väl lite tveksamt egentligen, lika bra att göra det ordentligt tänker jag. Det kanske kommer DDR5 med ECC också? Som sagt har jag dålig koll, har fortfarande DD3 i dessa maskiner

Permalänk
Medlem

Alla amd 5000 cpuer (utom APUerna 5700G och 5600G) stöder ECC.
Pro APUer dvs 5750G(GE) och 5650G(GE) stöder ECC

https://www.asus.com/se/support/FAQ/1045186/

kompletterat med strömsnåla GE varianter
Visa signatur

“There will be people that are burdened by only having the capacity to see what has always been instead of what can be. But don’t you let that burden you.”

Permalänk
Medlem

ECC on die hanterar bara att ram-minnena i sig har blivit skakigare när geometrierna blir mindre och allt skall gå snabbare - kort sagt för att åtminstone bibehålla tidigare nivå och kanske ytterligare marginal med låg felsannolikhet ett tag till innan ytterligare geometriminskning och ökad snabbhet har ätit upp den fördelen också och man måste hitta på ytterligare trix.

Riktig ECC-minne med extra minne för paritetsminne och ofta Hamming-baserad felrättning skyddar transporten från minneskretsarna in i till CPU/MMU och att minneskapslarna trots intern die-baserad ECC eventuellt läcker ut fel ändå då allt handlar om sannolikhet för fel inom bestämd tidsperiod.

Moderna datorer/servrar och OS som cachar och buffrar väldigt mycket data i RAM och stora minnesytor från 16 GB till flera hundra GB i servrar så ökar sannolikheten för fel ju mer minne som används i och med att 'träffytan' för 'fel' blir större ju mer RAM man har.

Av faktiska antalet inträffade fel så är det väldigt få av dem som upptäcks som konsekvens i programkörning eller att data får märkbar korruption i sin datahantering, som bitfel på färgen i grafiken under 3 ms i ett spel och är glömt sedan eller fel i en CAD-fil och reaktortanken i en kärnkraftverk blev tunn som konservburksplåt och kanske upptäcks mycket långt senare.

Om bitfel får kostsamma konsekvenser eller inte beror helt på platsen vid tillfället och går inte att predikera i förväg - därför försöker man ha så få RAM-fel som bara möjligt gentemot kostnaden som i servrar och arbetsstationer med kritisk design/kalkylering medans med tex. spel så kan man acceptera många fel i timme genom överklockning av CPU och RAM så länge det inte gör att spelet kraschar irriterande ofta.

Om man upplever att man får fel pga. misstänkt fel i RAM-minne så har man troligen redan haft tusen och tiotusentals fel redan innan (tex. i spel som börja krascha) och det är bara i MB/CPU med ECC-stöd som man har en chans att få reda på om man har fel eller inte då det fins register i moderkorts-chipen/CPU att fråga (tex. under /proc i linux) och i många fall lagras (som ECC-minne för servrar) också antalet fel permanent i livstidsräknare på själva minnesstickorna och överlever omstart av datorer.

Permalänk
Medlem
Skrivet av xxargs:

ECC on die hanterar bara att ram-minnena i sig har blivit skakigare när geometrierna blir mindre och allt skall gå snabbare - kort sagt för att åtminstone bibehålla tidigare nivå och kanske ytterligare marginal med låg felsannolikhet ett tag till innan ytterligare geometriminskning och ökad snabbhet har ätit upp den fördelen också och man måste hitta på ytterligare trix.

Riktig ECC-minne med extra minne för paritetsminne och ofta Hamming-baserad felrättning skyddar transporten från minneskretsarna in i till CPU/MMU och att minneskapslarna trots intern die-baserad ECC eventuellt läcker ut fel ändå då allt handlar om sannolikhet för fel inom bestämd tidsperiod.

Moderna datorer/servrar och OS som cachar och buffrar väldigt mycket data i RAM och stora minnesytor från 16 GB till flera hundra GB i servrar så ökar sannolikheten för fel ju mer minne som används i och med att 'träffytan' för 'fel' blir större ju mer RAM man har.

Av faktiska antalet inträffade fel så är det väldigt få av dem som upptäcks som konsekvens i programkörning eller att data får märkbar korruption i sin datahantering, som bitfel på färgen i grafiken under 3 ms i ett spel och är glömt sedan eller fel i en CAD-fil och reaktortanken i en kärnkraftverk blev tunn som konservburksplåt och kanske upptäcks mycket långt senare.

Om bitfel får kostsamma konsekvenser eller inte beror helt på platsen vid tillfället och går inte att predikera i förväg - därför försöker man ha så få RAM-fel som bara möjligt gentemot kostnaden som i servrar och arbetsstationer med kritisk design/kalkylering medans med tex. spel så kan man acceptera många fel i timme genom överklockning av CPU och RAM så länge det inte gör att spelet kraschar irriterande ofta.

Om man upplever att man får fel pga. misstänkt fel i RAM-minne så har man troligen redan haft tusen och tiotusentals fel redan innan (tex. i spel som börja krascha) och det är bara i MB/CPU med ECC-stöd som man har en chans att få reda på om man har fel eller inte då det fins register i moderkorts-chipen/CPU att fråga (tex. under /proc i linux) och i många fall lagras (som ECC-minne för servrar) också antalet fel permanent i livstidsräknare på själva minnesstickorna och överlever omstart av datorer.

Det var därför jag länkade till den tråden så att @MsSmith kan grotta ner sig lite mer i det, då jag inte har stenkoll, men ville vara hjälpsam och peka i rätt riktning.
Tack för förklaringen, jag blev nog bara mer förvirrad men förhoppningsvis hjälper den TS.

Visa signatur

*5600|B350M-A|16GB|GTX980Ti|GX750W|Core V21|280AIO|1TB+500GB.

AMD Ryzen 5(Zen3) @4891|Asus Prime|Corsair 2x8 LPX3000C15 @3200C16|Nvidia Geforce |Seasonic Focus| Thermaltake mATX kub|Arctic freezer II| NVMe SSD PCIE 3.0x2 Kingston A1000 1500/1000 + 2,5" HDD Western Digital Black Scorpio.

Permalänk
Medlem
Skrivet av xxargs:

ECC on die hanterar bara att ram-minnena i sig har blivit skakigare när geometrierna blir mindre och allt skall gå snabbare - kort sagt för att åtminstone bibehålla tidigare nivå och kanske ytterligare marginal med låg felsannolikhet ett tag till innan ytterligare geometriminskning och ökad snabbhet har ätit upp den fördelen också och man måste hitta på ytterligare trix.

Riktig ECC-minne med extra minne för paritetsminne och ofta Hamming-baserad felrättning skyddar transporten från minneskretsarna in i till CPU/MMU och att minneskapslarna trots intern die-baserad ECC eventuellt läcker ut fel ändå då allt handlar om sannolikhet för fel inom bestämd tidsperiod.

Moderna datorer/servrar och OS som cachar och buffrar väldigt mycket data i RAM och stora minnesytor från 16 GB till flera hundra GB i servrar så ökar sannolikheten för fel ju mer minne som används i och med att 'träffytan' för 'fel' blir större ju mer RAM man har.

Av faktiska antalet inträffade fel så är det väldigt få av dem som upptäcks som konsekvens i programkörning eller att data får märkbar korruption i sin datahantering, som bitfel på färgen i grafiken under 3 ms i ett spel och är glömt sedan eller fel i en CAD-fil och reaktortanken i en kärnkraftverk blev tunn som konservburksplåt och kanske upptäcks mycket långt senare.

Om bitfel får kostsamma konsekvenser eller inte beror helt på platsen vid tillfället och går inte att predikera i förväg - därför försöker man ha så få RAM-fel som bara möjligt gentemot kostnaden som i servrar och arbetsstationer med kritisk design/kalkylering medans med tex. spel så kan man acceptera många fel i timme genom överklockning av CPU och RAM så länge det inte gör att spelet kraschar irriterande ofta.

Om man upplever att man får fel pga. misstänkt fel i RAM-minne så har man troligen redan haft tusen och tiotusentals fel redan innan (tex. i spel som börja krascha) och det är bara i MB/CPU med ECC-stöd som man har en chans att få reda på om man har fel eller inte då det fins register i moderkorts-chipen/CPU att fråga (tex. under /proc i linux) och i många fall lagras (som ECC-minne för servrar) också antalet fel permanent i livstidsräknare på själva minnesstickorna och överlever omstart av datorer.

Toppen, tackar! Som vanligt ett mycket informativt inlägg. Känns som att ECC blir mer och mer viktigt och vill inte vara utan egentligen.

Skrivet av Fenrisulvfan:

Det var därför jag länkade till den tråden så att @MsSmith kan grotta ner sig lite mer i det, då jag inte har stenkoll, men ville vara hjälpsam och peka i rätt riktning.
Tack för förklaringen, jag blev nog bara mer förvirrad men förhoppningsvis hjälper den TS.

Tack, ska erkännas att jag heller inte förstod allt men det räckte för mig att läsa att i och med att hastigheten ökar så ökar risken för fel för att jag ska ta beslutet att ECC även i framtiden är ett måste.

Permalänk
Medlem

Den andra delen som är drivande är att datamängderna som hanteras idag är mycket större än för tex. 20 år sedan då sannolikheten fel per Mbyte data per tid är ganska konstant för var generation med RAM - har man allt större working-set så är sannolikheten att det blir någon bitflip inom workingset också större och skalar linjärt med hur mycket minne man allokerar för jobbet...

Har man en process som ryms inom 1 Mbyte så kanske inträffade bitfel är 10 gång per 1 miljard timmar (10 FIT/MB [FIT = 'Failures in Time' per miljard timmar per kB/MB/GB/minnesmodul])) - har working-set vuxit till 10 GByte så är det nere på 10000 timmar innan första bitfel inom working-setet inträffar (samma FIT-värde per MB och då är sannolikheten att en bitflip har inträffat inom 2 år istället för över 1000 år)

Nu finns det inge RAM-minnen med 10 FIT/MB utan det handlar mer om 2000 - 5000 FIT/MB före eventuell rättning ala. ECC, jag har ett svag minne att SUN på sin tid hade oerhört svårt att komma under 200 FIT/MB RAM och insåg att paritet och felrättning var en nödvändighet.

Att minnesfelen med 1-bitsfel är betydligt mer ofta än vad folk hoppas på kan man läsa om här https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd...

Hur mycket FIT sänks med die-baserad ECC för DDR5 verkar inte gå att hitta - det är överlag väldigt dåligt med information i vad tillverkare lovar i FIT för sina RAM-moduler och det enda man kan gå på är olika stora fälttester (som google/facebook/amazon och olika myndighetsverksamheter) och de forskningsrapporter som genereras därifrån - och det är alltid på ECC-minne då det är enda sättet att faktiskt mäta antalet bitfel i verklig verksamhet och då kan man inte helt utesluta att ECC-logiken i sig också kan generera fel som kanske inte syns på minnen utan ECC.