Ja detta är ju en diskussion som pågått i 20 år, det är inte bara Linus T som drivit den. Men problemet med random minnesfel skalar ju med mängden minne man använder (egentligen dess throughput), och med tanke på hur mycket minnesanvändandet ökat de senaste 20 åren, så blir ju bristen på ECC en mer brännande issue med tiden. Inte konstigt att diskussionen briserar då och då, med ökad intensitet minst fram till dess att DDR5 rullas ut
Detta från Linus T tycker jag plockar ut poängen:
Skrivet av Shiprat:
Don't fall for the bullshit. ECC is not for servers. ECC is for everybody, and wanting to pay a bit extra for RAM shouldn't mean that you are then limited in other ways.
Linus
"Limited in other ways" är problemet, oftast finns inte alternativet att betala en rimlig merkostnad för ECC
utan att offra något mer.
Själv har jag övervägt ECC vid alla köp sen 10 år tillbaka, i tävling med andra features som ofta fått vinna i slutändan. I mitt fall inte features som möjligheten att klocka minnen över JEDEC, har aldrig varit intresserad av det, men antal kärnor mm. När jag köpte min 6c Coffe Lake i signaturen letade jag ECC-alternativ, men närmaste alternativet hos Intel var Kaby Lake Xeon E3 med 4 kärnor. Eftersom 4c var för lite för mig, så föll det bort då (tittade på AMD också, men oklarhet kring IOMMU samt bristen på iGPU avgjorde i slutändan). Så det är inte bara prisskillnaden som spelar roll.
Torvalds generella poäng är ju dock mer den status, support och nytta för majoriteten användare som ECC hade kunnat ha om det inte varit för segmenteringen. Det är såklart en annan sak än mina och andra swecares entusiastpreferenser. Jag tycker han har bra poänger kring detta, särskilt som sagt när 32Gb ram snart är mainstream, och nya riggar klarar 128Gb.
Skrivet av Yoshman:
Här tycker jag data inte alls styrker att primära drivfaktorn för marknadssegmentering är att öka lönsamheten för serversidan. Torvalds har helt rätt i att Intel har segmenterat ECC stödet till servers och "embedded", men kollar på de CPU-modeller som finns både med och utan ECC stöd är prisskillnaden konsekvent <10 %. Kollade upp ett par i3-modellerna som finns i "embedded" variant (som har ECC) stöd, de var <5 % dyrare än motsvarande desktop-variant.
D.v.s. råder inget tvivel om att Intel segmenterat marknaden, men orsaken kan knappast vara för att öka lönsamheten på produkter med ECC-stöd då prispåslaget är helt enkelt så litet att det knappast kan göra mer än täcka den faktiska merkostnaden.
Påslaget för ECC varierar och verkar vara större när vi går uppåt i prestanda, ta t.ex. Xeon W-2265 vs. I9 1920X, där är Xeon 35% dyrare för såvitt jag kan se samma kisel och klocka (introduktionspris enligt ark: 944usd vs. 700usd). Lägg till det tidslagget för release mellan konsument- och workstationversionerna av samma processor. Hur det kvantifieras i pengar är såklart subjektivt för användaren, men Intels marknadsavdelning har garanterat en beräkning på vad det gör för skillnad för företaget.
Men, du har säkert rätt i att det finns fler skäl bakom segmenteringen än bara prisskillnaden. Jag förstår såklart att det finns en massa fördelar med att låta enterprise-hårdvaran lagga efter 6 månader så att gamers och inte företag får upptäcka evt. hårdvarubuggar. Om det istället varit samma hårdvara - ja, marknadsstrategierna hade behövt vara rejält annorlunda, det är helt säkert.
Citat:
Kikar vi på SweClockers testar kring hur minneshastighet påverkar minnesprestanda blir då den verkliga frågan: vilket värde skulle ECC ge för dagens gamers? För vad de faktiskt kommer "se" är ~10 % högre pris och upp till ~10 % lägre prestanda med noll skillnad i upplevd stabilitet (om man nu inte överklockat sitt system idag till en nivå där det kraschar ett par gånger per år)...
Jag tycker Linus T har en stark poäng om nyttan även för klockare, även om det såklart var ett sidospår (han svarar väl på påståendet att gamers inte behöver ECC). Poängen är väl inte att felkorrigeringen hos ECC ska kompensera för alltför hårt klockade minnen genom att rätta felen, utan att överklockare ska kunna få veta när bitfelen drar iväg. Men självklart kommer man att nå taket tidigare med minnen som är oförskämda nog att tala om för en när maskinen börjar bli instabil... finns garanterat de som föredrar att vara lyckligt ovetande istället.
Givetvis förutsätter det att branschen tänker annorlunda kring både ECC och minnesklock/timings, hade ECC varit seriöst etablerat i alla segment så hade vi haft en annan idé om hur långt minnen kan pressas, och vad stabilitet innebär. Men det är lite inbyggt i argumentet att den resulterande idén hade varit en bättre idé, baserad på information som vi i teorin kan få (med ECC) men nu inte ens har. Var vi hade varit om allt arbete som gjorts för att uppfinna snabbare minnen, gjorts med hänsyn till ECC, vet vi såklart inte. För att "vi" (Intel, branschen, ...) har valt att inte veta det.
Skrivet av Yoshman:
Tänk igen och läs också vad Torvalds skrev i första inlägget: grejen med de fel som ECC kan rätta är att de i majoriteten av fallen är "tysta", d.v.s. oavsett hur teknik-kunnig man är kommer man inte kunna göra något åt felen då man inte ens kommer se dem. Det var min invändning mot det jag markerade.
I första inlägget klagar Torvalds specifikt på att vi aldrig kommer få veta hur vanligt fel som t.ex. Rowhammer faktiskt är då dessa är nästan alltid "osynliga" (i.e. de ger inget fel som kan observeras), vilket är en helt korrekt observation men som går i klinch med att man inte behöver ECC om man är "tech savy".
Jag ser inte någon inkonsekvens i Linus argument, hela hans poäng med inlägget (om man tar honom på orden) är ju att det inte är hans behov som är de viktiga. Rowhammer och random bit flips är ett problem, det faktum att man inte får veta utan ECC att minne är instabilt eller håller på att gå sönder är ett annat. Man kan försvara olika fördelar med ECC för olika användare, samtidigt. Correction och detection är olika diskussioner, men såklart kommer ens "tech-savyness" att styra hur länge det tar att upptäcka ett trasigt minne om man inte har ECC med fungerande felrapportering. Med ECC däremot, då är tech-savyness inte en faktor längre, precis som det bör vara.
Hans argument om gamers fokuserar också uppenbart på detection, inte correction. Poängen är ju att ECC fixar båda. (hade man velat hitta en sweet spot för att monitorera överklockning hade det kanske räckt med en enklare paritetslösning, t.ex. en checksum-bit per 64bit eller så för enbart detection, vilket hade varit betydligt billigare än ECC. Men paritet har väl inte förekommit sen SIMM-tiden, antar jag?)
Skrivet av ddelin:
När det gäller AMDs AM4 plattform stödjer dom ju officiellt ECC på Pro varianterna av CPUerna, så risken för att man skulle få nån dummy implementation som rapporterar att ECC är på fast det inte funkar tror jag inte på, även med icke Pro varianterna av Ryzen. Stödet finns ju uppenbarligen både i kislet, och i firmware, och enligt AMD finns det inget tekniskt som begränsar användningen i vanliga Ryzen proppar.
Skrivet av anon5930:
Hade varit ganska fint om även AMD erbjöd egna referensmoderkort som följer tanken bakom plattform, där officiellt ECC-stöd också erbjuds. Är inte partnertillverkarna inte intresserade så får AMD göra deras jobb helt enkelt.
Jag började gräva i ECC-stödet på AM4 i en annan tråd nyligt. En del av hindren för utbrett ECC-stöd på AM4-moderkort är att även om fel korrigeras, så loggas de inte av moderkortet pga att plattformen inte stödjer detta (enligt mejlkorrespondens under 2019 mellan AMD-ingenjörer och ASRock Rack, se länkade inlägget). Verkar finnas mjukvaru-workarounds för loggning, men avsaknaden av loggning enligt standard bidrar kanske nog till att moderkortstillverkarna inte så entusiastiskt försöker göra ECC till en feature. Så ansvaret ligger ganska mycket hos AMD också.
Jag såg i mejltråden som Linus T skriver i, att Ian Cutress explicit tar upp risken att AM4-riggar rapporterar ECC-stöd utan att det fungerar. Det kan dock bygga på fall där felkorrigeringen fungerar, men rapporteringen inte gör det, vilket såklart gör det till en definitionsfråga om man ska säga att "ECC fungerar" eller inte.
Gräver gärna vidare i detta, fast kanske hellre i den andra tråden, känns som att vi inte behöver en "Men AMD då?"-diskussion här
