10 hónapot sem bírtak az ECC memóriák Linus gépében

Címkék
[...]

The biggest hiccup last week was that I had correctable ECC memory
errors in my machine and had to replace my DIMMs once again. But at
least this time I got nice warnings about how my memory was going bad,
so it was only a fleeting annoyance.

[...]

Tavaly ősszel RAM-hiba hátráltatta Linust a kernelkarbantartói munkájában és amiatt RAM-moduljai cseréjére kényszerült. Az új modulok kb. 10 hónapig bírták hiba nélkül. Múlt héten Linus ismét (correctable ECC) RAM-hibákat fedezett fel gépében, így a modulokat újra kicserélte. Annyival volt jobb most a helyzet a tavaly őszivel ellentétben, amikor is sunyi, véletlenszerűen előforduló, nehezen megfogható hibákkal küzdött, hogy most szép figyelmeztető üzeneteket kapott arról, hogy mi a baja a moduljainak, így csak egy gyorsan orvosolható kellemetlensége volt. 

Hozzászólások

Minden tisztelet Linusnak, de nem vagyok feltétlen biztos benne, hogy szélesebb körű tesztek nélkül, webshopokból összevissza rendelt modulokkal megfelelő, stabil gépet kap. Remélhetőleg az alaplapgyártó kompatibilitási mátrixát nézni és az ajánlott modulok közül rendel, nem csak random, nagy vonalakban megfelelőt.

trey @ gépház

Pusztán lehet, hogy az ilyen RAM-hibák nem RAM-hibák, hanem alaplap/memória időzítési problémák, szarul megválasztott, megméretezett tápegység hibák, vagy szar tápegység által okozott bizonytalanságok, előidézett meghibásodások, amik egy rendesen megtervezett rendszernél ezzel a modullal elő sem jönnének. 🤷‍♂️

Ez csak egy példa arra, hogy miért nem jó kíséretezni.

trey @ gépház

Most jöhetnék olyan további logikus kérdésekkel, hogy mégis mit csinált 10 hónapig az az időzítési hiba vagy bármi más, meg hogy miért oldotta meg a modulok cseréje, de azt érzékelem, hogy ez a "vegyél brand gépet" amolyan érzelmi önmegnyugtató viselkedésforma azoknál, akik hisznek a nagy nevekben.

Linus meg úgy tűnik hisz az egyszerű dolgokban, meg önmagában.

Valószínűtlennek, de nem lehetetlennek tartok egy ilyen hibát: ha a határon működött a RAM, akkor egy kicsit öregedett azóta, most már kiment a normál tartományból.

Azt kell látni, hogy hiába digitális elektronikáról beszélünk, az alaplapon azért egyelőre még analóg jelek közlekednek. Márpedig a mai memória órajeleken nem is nagyon lehet máshogy.

Tudtommal a memóriabusz a mai napig nem differenciális (DDR4-ig biztosan nem), ellenben a kommunikációs buszokkal. Nyilván szeretnék a lehető legnagyobb memória sávszélességet biztosítani.

De már a chipgyártók is küzdenek ezeken a sebességeken, akkor mit szóljon az alaplap gyártó? Neki soha nem lesz annyira jól kontrollált technológiája, mint a szilíciumnak, a jeleket pedig nem mm-ekre, hanem 15-20 cm-ekre kell vinni. Hosszkiegyenlítéssel, a jelek egymásra hatására és az impedanciára is figyelve.

Beindítasz egy új rendszert, ami épp a határon, de elketyeg. Szuper. Öregszik, a RAM-ban vagy a processzorban lévő vonalmeghajtók kicsit veszítenek az erejükből, kicsit bemelegszik a rendszer, és valamilyen adatot tévesen fog 0 helyett 1-nek venni, vagy fordítva.

Most nem tudjuk, hogy tényleg ez történik-e, vagy tényleg egyszerűen csak sz*r a RAM, és nem tartja meg az értékét.

a jeleket pedig nem mm-ekre, hanem 15-20 cm-ekre kell vinni

Ilyet néhány évdizede sem láthattál. ;)

Azt kell látni, hogy hiába digitális elektronikáról beszélünk, az alaplapon azért egyelőre még analóg jelek közlekednek. Márpedig a mai memória órajeleken nem is nagyon lehet máshogy.

Roppant szellemes megfogalmazás! Tehát digitális buszon analóg jelek közlekednek, amelyet a minden vonal végén elhelyezkedő 1 bites DAC alakít digitálissá. Esetleg a Core i9 is analóg processzor, csak a féleszű Intel sem tud róla? :-D

Öregszik, a RAM-ban vagy a processzorban lévő vonalmeghajtók kicsit veszítenek az erejükből, kicsit bemelegszik a rendszer

És adatlapot láttál-e már?

És adatlapot láttál-e már?

Nem keverem, csak megpróbáltam tréfás, cinikus, stb.módon kifejezésre juttatni,: baromság.

Sajnos úgy néz ki, hogy szakemberek helyett filozófusok próbálják osztani az észt. Ebben az esetben olyannak, aki véletlenül pont ebben a szakmában dolgozik.

Fussunk neki mégegyszer!
 

Definíció: Az 1. szintet a piros golyó jelenti, a 0 szintet a fekete golyó.

Ellenőrző kérdés: Melyik szintet jelenti a sárga golyó? És a zöld?

(Válasz: Egyik szintet sem jelenti.)

Egy akármilyen adatlap - ami éppen meg van nyitva az orrom előtt:
 

Peremfeltétel: 4.5V <= VDD <= 5.5V

Definíció: VIH (1 szint) min. 2V, VIL (0 szint) max 0.8V

Ellenőrző kérdés: Melyik szintet jelenti az 1.2V. És az 1.8V?

(Válasz: Egyik szintet sem jelenti.)

Szóval mindkét válaszból kiderül, hogy az analóg jel egyes értékei nem értelmezhetők a digitális vonalon. És ez jó, mert ezen az úton eljuthatun a zajvédettséghez is...

Mit tudunk még?

  • Az áramkör (amelynek része a nyomtatott áramkör is) a fizikai térben és valóságban helyezkedik el. Ezért a fizika törvényei érvényesülnek.
  • A fenti miatt nem lehetséges a végtelen sebességű feszültségváltozás: dU/dt << ∞ Így aztán pl. 0->1 átmenetkor a feszültség felvehet tetszőleges értéket (bizonyos határértékeken belül), de ettől még nem lesz "analóg" jel.
  • Az emlegetett áramkörök (CPU, RAM) általában szinkron üzeműek. Tehát - ahogy kb. írtad - adott időre megérkezik és adott ideig fennál az 1 érték, akkor az 1 lesz.
  • Az átmenet és/vagy nem vizsgált időpontokban a jel lehet kiscica-alakú is. Ez mitsem változtat azon, hogy az egyik kitüntetett pontban 0, a másikban 1 az értéke.

Jó 30 éve jegyezte meg egy amatőr: "Rámértem szkóppal a Z80 buszára és nagyon zajos."

Hol a hiba? Ogyanott, ahol a fenti okoskodásokban. Ha a buszt oszcilloszkóp (ami jobbára analóg jeleket vizsgáló eszköz) helyett logikai analizátorral mérjük, és a gépi ciklushoz illetve az órajelhez szinkronizálunk, akkor pontosan a digitális információhoz jutunk hozzá.Ekkor kiderül, hogy a zajosnak tűnő busz egész pontosan működik. A "zajt" részben az okozza, hogy egyes esetekben a busz Hi-Z állapotba kerül és a kis értékű szivárgok áramok viszonylag lassan töltik vagy kisütik a buszon levő kapacitásokat. Ennek ellenére nem jó az a megállapítás sem, hogy a Z80 busza gyakran kanyar alakú analóg jeleket tartalmaz. :-D Ha valakit ez zavar, akkor felhúzó ellenállásokat kell a buszra kötni, amitől a hosszú  kanyargó jelek eltűnnek, miközben a logikai analizátorral mért eredmény változatlan marad.

Jöhet a folytatás:

Ellenőrző kérdés 2: Melyik szintet jelenti a 2V. És a 4.8V?

Ebben az esetben az "analóg jel" két külöböző értéket vesz fel, de mindegyik logikai 1, mert ez egy digitális jel. És hiába kiscica-alakú a 2 és 4,8V között, továbbra is digitális jel marad és folyamatosan 1  a logikai értéke.

Az analóg jelet legtöbbször folytonos fizikai mennyiség reprezentálja

Írja még a wiki is. Ezzel szemben a digitális jel véges számú diszkrét (itt a fizika miatt határ-) értékkel jellemezhető.

Amit félreértesz az az, hogy nem kell és sok esetben nem is lehet biztosítani a pontos 0 és 1 értékeket, tehát a digitális vonal (mondjuk VSS-0.3V..VDD+0.3V) folyamatosan vehet fel értéket, de ez lényegtelen. Ami lényeges, hogy adott pillanatban a specifikált 0 és 1 érték alatti vagy feletti érték van-e. Ha igen, akkor jó a jel. Ha nem, akkor pl. a buszhoz túl közel mobilozol. :-D

Kedves bucko!

Ebbe most nem fogok belemenni. Én tisztában vagyok vele, hogy tudod miről beszélsz, de nem túl sportszerű nekiesni egy hsz-nek először óvodás szinten, majd előhúzni a zsebből az egyetemi anyagot.

Amit most csinálsz, az az óvodás szint, a Z80 memóriabuszát a DDR4-hez hasonlítani, és nem várom meg a másik végét. Nagyon leszokhatnál már erről. Nem azért, mert nem ugyanazokra az elvekre épül, ez természetesen igaz, csak épp a Z80 korában messze nem volt annyira kihegyezve a digitális elektronika, nem voltak olyan buszsebességek, amik már bőven a vezetősáv hosszával összemérhetők, nem volt gond azt meghajtani, nem kellett hullámvezetőként kezelni. Tudom hogy már láttál szem-ábrát, tudod nagyon jól, hogy a digitális tervezés csúcsa az pedig kőkemény analóg szívás. Nem azért, mert nem 1-eket és 0-ákat akarunk átküldeni, hanem azért, mert a fizikai jel folytonos, egymásra hatás van, reflexió van, stb.

Lehet tenni a hülyét, hogy az analizátor csak 0-1-eket fog kiírni, de ezek olyan hatások, amiket a 40 évvel ezelőtti digitiális tervezők nyugodtan figyelmen kívül hagyhattak, és az analizátor tényleg azt is mutatta, amire rákötötted.

 

De felteszem ezzel a logikával nálad a RAM teszt is elég egyszer teleírni 1-el, egyszer 0-val, a memtest írói pedig csak a billentyűzetet koptatják, amikor mindenféle trükkös mintával próbálják előcsalogatni a RAM hibákat. DEHÁT AZ ADATLAP MEGMONDTA HOGY JÓ LESZ, NEM? Az adatlapok pedig nem szentírás, ezt mindegyik le is írja, nem egyet fogtam már, amiben csak az IC egyik fő funkcióját nem tudta, gyártónak szólva is lett miatta.

Hát nagyon nem. És bizony nem egy olyan RAM-al találkoztam én is, pedig messze nem dolgozok olyan szintű géppel mint mondjuk trey, hogy az a RAM simán átment egyszer, csak járatni kellett 10 órát, és csak kijöttek a hibák. Pedig se overclock semmi.

Részemről befejeztem ezt a thread-et, de ismerlek, majd jön a válasz úgyis, hogy te már mindent 40 éve is így csináltál, és csak mi vagyunk a hülyék. Nyugodtan írd le, én pedig nyugodtan ignorálni fogom. Köszönöm!

Köszönöm a lebaszást! Biztosan én írkálok marhaságokat, ráadásul óvodás szinten, ami egyébként nem egyetemi anyag, csak egy adatlap, amit itt a hupon már mindenki látott és helyesen értelmezi.

Amit most csinálsz, az az óvodás szint, a Z80 memóriabuszát a DDR4-hez hasonlítani

Ilyenkor szoktam javasolni a Texas Instruments: TTL receptek. Budapest, MK. 1979.  elolvasását, vagy ismételt elolvasását. Utána sokkal könnyebb lesz egy áramkör vagy adatlap értelmezése. ;)

Bár az eredeti könyvet '72-ben írták, de a fizika ezen a szinten azóta sem változott.

csak épp a Z80 korában messze nem volt annyira kihegyezve a digitális elektronika, nem voltak olyan buszsebességek, amik már bőven a vezetősáv hosszával összemérhetők, nem volt gond azt meghajtani, nem kellett hullámvezetőként kezelni

Persze, a Z80 csak egy példa volt, bár abban a korban már legalább egy nagyságrenddel gyorsabb áramköröket használtak. Bizony, így van ez, nő a frekvencia és csökken a hullámhossz. Bár az alkatrészek mérete csökken és a (tároló) kapacitása nő, amik csökkentik a vezetékek hosszát. Ennek ellenére csak annyi különbséget látok, hogy pontosabban kell számolni és gyártani. A képlet ugyanaz, mint 50 éve volt. ;)

Mindezek ellenére a digitális jelből akkor sem lesz analóg, ha pl. a hibásan illesztett vezetéken visszaverődik. Nyugodtan ignorálhatod.

Szinte igazad van, de rosszul ejted a szavakat. ;)

A valóságban csak fizikai jel van. (drót, villany, idő)

Legyen két drót, amelyeken 0..3,3V közötti értékek fordulnak elő. (Szerinted ez analóg.) A drótok első végeit (ésszel) bedugjuk valahova, nos onnan jönnek a jelek.

A drótok másik végét bedugjuk egy 3,3V-os digitális áramkörbe, illetve egy hifi erősítőbe. Mindegyik jól "muzsikál", de az egyik digitális, a másik analóg jelet tud értelmezni. Igen nagy valószínűséggel a drőtok első végén a megfelelő jelet sikerült beadni.

A drótok második végét cseréljük fel! Mindkét szerkezet jól muzsikál! Bakker, ezek hibrid jelek! :-DDD Nem. Minden jel analóg. Vagy minden jel digitális?

Pedig mindkét esetben ugyanaz történt. Az adatforrás megkísérelte a megállapodás szerinti folyamatos (analóg) vagy diszkrét (digitális) értékeket eljuttatni a drótra. Ezt a fizika többé-kevésbé megakadályozta. A másik végen a jelnek megfelelő "értelmező" feldolgozta a jeleket. Minden esetben az adatot kibocsátó forrás szándéka és a fogadó értelmezése szerinti jelekről beszélünk. A többi csak nemkívánt torzítás, azaz a jel jellegét nem befolyásolja.

A fizikai réteg fizikai, az információs réteg megegyezés szerinti. Ez utóbbi lehet pl. digitális vagy analóg.

Ezt tanítják valahol, vagy a saját értelmezésed?

A valóságban csak anyag van, ami vezet amennyire vezet, ha van mit vezetni (pl. villanyt? :-) ).  Ez a vezetés analóg jelként mindig értelmezhető, bárhová is dugsz bármit.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Ok, legyen a saját értelmezésem. A gyakorlatban egy digitális áramkör mérésére teljesen más a bevett gyakorlat és műszerpark, mint az analóg jelek mérésére. Még akkor is, ha mindkettőre néha oszcilloszkópot kell használni. Tulajdonképpen az oszcilloszkóp a digitális jelen legfeljebb a hibás működés, specifikáción kívüli működés (időben vagy feszültségben) ellenőrzésére szolgál.

Ha már feltetted a kérdést, akkor tényleg mutassál tananyagot arra, hogy az elektromos átviteli közegen (dróton) folyó áramot "analóg jelként" kell értelmezni. Az értelmezhető elég gyenge megfogalmazás, mert megiszok egy felest és esszét írok arról, hogy hő/mágneses/turbulens hatása alapján is mindig értelmezhető. Ugye nem beszélgetsz a porszívóddal amikor bekapcsolod: No, öreg, kapsz egy kis analóg jelet a seggedbe! :-D

És itt a bukfenc! A hálózati 50Hz nem is jel, mert ebben a formájában nem is információ továbbítására használod. És ebben a pillanatban "Kevered a fizikai réteget az azon továbbított információs rétegekkel." - mint ahogy állítottad rólam. Gyűrűzzön hát tovább a magyarázat! Az 50Hz azt az információt továbbítja a motornak: Forogj, folyamatosan! Uri Geller pedig: Múkodj! :-D

Azt hiszem, eléggé eltávolodtunk a digitális adatbusz egy vonalán (line vagy lane) haladó jel értelmezéséről. ;)
 

Az értelmezhető a pontos megfogalmazás. Ha szükségesnek látom értelmezem, ha nem nem, semmi nem kötelező. Viszont a lehetőség adott. Gyakorlatilag ezt írod le az első bekezdésben is. Egy ismeretlen jelet senki nem kezd el logikai analizátorral vizsgálni (lehet Te igen :-) ), hanem a jő öreg szkópot veszi elő, ami analóg műszer. A tanagyagokat pedig inkább hagyjuk. Az számomra pozitív, hogy saját értelmezésed, még ha nem is értek vele egyet.

Az 50Hz-el kapcsolatban csak ki kell egészíteni a korábbi állításomat: Kevered a fizikai réteget az azon továbbított energiával vagy információs rétegekkel.

Szerintem engedjük el a dolgot.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Igen, láttam adatlapot, meg oszcilloszkópot is digitális buszon.

Ezt írod: Szóval mindkét válaszból kiderül, hogy az analóg jel egyes értékei nem értelmezhetők a digitális vonalon. 

Viszont ettől még a jel analóg, csak nem értelmezhető digitálisan - de ettől még előfordulhat ez a jel azon a buszon hiba esetén. Pont ez a lényeg. Akkor lenne a busz valóban digitális, ha más jel fizikailag sem fordulhatna elő, nem lehetne előidézni köztes értéket a buszon. Normál működésben nem is lehet, de most pont a hibás működésről beszélünk, amikor előfordul ilyen, digitálisan nem értelmezett jel. Rámérsz egy hibás buszra digitális analizátorral, és nem fogja tudni értelmezni. 

 

Nem az a kérdés, hogy hogyan próbáljuk meg a fizikai analóg jeleket digitálisra közelíteni (szerintem itt a fórumon mindenki tudja, hogyan is működik a digitális technika), hanem az, hogy mi van akkor, amikor ez a közelítés hibádzik. Mert pont ilyenkor van bithiba a buszon. Kap a digitális busz egy olyan jelet, ami mind a 0, mind az 1 jel érvényes értékén kívül van, az áramköri elemek ezek alapján valamilyen állapotba beállnak (mert az áramkör valamit fog csinálni, valaminek történnie kell), csak éppen nem abba, amit a busz másik vége akart. Így lesz az, hogy ami a busz egyik végén még 0 volt, a másik végén már 1 lesz. Hiába digitális a busz.

Pedig az adatlap specifikálja a digitális áramkör működését a megadott körülmények mellett. Ha a "külvilágot" kell meghajtani, akkor kisebb frekvencián a terhelő kapacitás, nagyobb frekvencián a terhelő impedancia és késleltetés megadásával. Ha jó az áramkör és a tervezők betartották az előírásokat, akkor tapasztalhatod az elvárt, azaz a hibátlan működést. Ha meghibásodott az áramkör, vagy a meghajtott  "külvilág" paraméterei megváltoztak  zavar, hőmérséklet, tervezési hiba, stb. miatt, és ezért nem a specifikált tartományban működik, akkor felléphet hiba.

A hiba ténye nem minősíti át a digitális vonalat (itt két diszkrét határérték értelmezésére képes) analóg vonallá (folyamatos értékek értelmezésére képes). Mindössze arról van szó, hogy az elméleti digitális értékek a valóságban nem léteznek. Pl. a 0->1 átmenetnek van felfutási ideje, mert a buszon látszó kapacitásokat nem végtelen árammal fel kell tölteni. Ez nem hiba, nem analóg jel, és megfelel a specifikált feltételeknek. Ha a jel nem felel meg a specifikált feltételeknek vagy pl. a busz végén csücsülő áramkör nem teljesíti a specifikációt, akkor beszélhetünk hibás működésről. Ebben az esetben az analizátor is hibás értékeket mérhet.

Ha meghibásodott az áramkör, vagy a meghajtott  "külvilág" paraméterei megváltoztak  zavar, hőmérséklet, tervezési hiba, stb. miatt, és ezért nem a specifikált tartományban működik, akkor felléphet hiba."
De pont erről beszélünk! Ekkor előfordulhat olyan jel a buszon, amelyik nem esik bele az adatlap tartományaiba. A busz nem digitális olyan értelemben, hogy fizikailag lehetetlen a specifikált feszültségen kívül eső jelet rajta átküldeni, mivel bármilyen feszültség mehet rajta - a valóságban analóg jelek közlekednek.

Senki nem mondta, hogy a vonal analóg, csak azt, hogy a vonalon a feszültség nem diszkrét értékekben közlekedik (a vonal nem kvantummechanikai rendszer), nem lehet kizárni ezt azt mondva, hogy a busz digitális és kész.

És az egész szál arról szól, hogy igen, hiába digitális egy busz, van rajta hiba, mert fizikailag nem zárható ki, hogy olyan jel legyen a buszon, ami nem értelmezett digitálisan. Ugyanis a buszon fizikailag analóg (klasszikus elektrodinamikával leírható) jelek mennek, nem kvantummechanikai diszkrét jelek.

A jel attól lesz digitális, mert mi annak tekintjük, hogy mittom a +5 V 2mp -ig, az 1 lesz, ha nincs semmi az meg nulla. Ez a fizikailag valójában egy 5V-os valami, ami jött és vége lett, a kutya nem tudja, hogy ez most mi a túrót reprezentál, mármint rajtunk kívül, akik úgy döntöttünk. Az áramkör attól digitális, hogy kifejezetten az ilyen jellegű jelzések kezelését szeretnénk tőle, és ennek megfelelő tervezte meg egy vagy több olyan, aki ehhez ért.

Jópár éve az ifabon vagy a másik hazai még meglévő infós kiállításon volt egy lézeres adattovábbító. A lényege az volt, hogy az akkor hajmeresztő 100Mbit/sec-et néhány 100 méterre minden viszontagsáon keresztül át tudta lőni. Namármost ez a gyakorlatban egy "veszett villogás", de ettől a fény nem lett digitális. :)

Amúgy DDR3 vagy DDR4-es adatlapot láttál már? Ezeknek a link training procedurájáról van fogalmad? ZQ kalibráció, DQ és DQS (strobe) skew kalibráció, read centering, write centering? Periodic recalibration?

Olvass egy kicsit utána pls, hogy például DDR4-nél hogy is van ez: https://www.systemverilog.io/design/ddr4-initialization-and-calibration/

Régóta vágyok én, az androidok mezonkincsére már!

Utánaolvastam, most sántítok, mer nagy kő gördült le a kis szívemről és ráesett a tyúkszememre. Egészen idáig úgy gondoltam, hogy zsokénál is kisebb termetű kici kinjiak kici cavarhuzóval csücsülnek minden csipben és ők végzik el a finombeállítást. :-D

Ezek a technológiák nem DDR3 vagy DDR4 specifikusak. Mindegyik megtalálható egyéb, akár kisebb frekvencián működő digitális és analóg áramkörökben is.

Azért van így, mert ott tart a technológia, hogy amit régen diszkrét áramkörökkel csináltak - vagy emiatt lehetetlen volt -, ma már lehet integrálni és automatizálni. A további okok egyrészt az áramkörök (úgy értem a már szerelt) egyedi, ekkora részletességű bemérése a horribilis költségek miatt lehetetlen, de fizikailag sem könnyű megfelelő mérőfejet az kész áramkörhöz illeszteni. Másrészt a hibát triviális megmérni magával a beállítandó eszközzel. Ha a programozható környezet is rendelkezésre áll, akkor még könnyebb elvégezni a mérést és beállítást.

Korábban ezt nézegetem, hogy mit is kell biztosítani egy ilyen ramnak. Elég precíz specifikáció.

Na hát, ha ezzel így mind képben vagy, akkor vajon miért Z80-as, TTL-korszakbeli példákat hozol?

Másrészt gondolom azzal a részével is tisztában vagy, hogy ennek a runtime beállítási folyamatnak vannak olyan részei, amelyekre az egyes gyártó cégeknek saját féltve őrzött proprietary algoritmusai vannak. Vagyis hiába precíz a specifikáció, ha A vendor nem próbálja össze a termékét B vendor termékével, akkor lehetnek meglepetések. Nem _kéne_, hogy baj legyen belőle, mert vannak standardizált teszt procedúrák, de mégis előfordult, hogy X processzor Y gyártó memóriájával eleinte nem működik, vagy csak nagyon lerontott órajelen és időzítésekkel megy, és ki kell adni egy firmware (ez az AMD-nél az AGESA) update-et, ami javítja. Nem az analóg csatorna paramétereivel van a baj, hanem annak kompenzálására kitalált paraméterek beállításáról vannak eltérő elképzelései az egyes vendoroknak.

"fizikailag sem könnyű megfelelő mérőfejet az kész áramkörhöz illeszteni" - Konkrétan megvásárolható kész eszközök vannak rá, pl Rhode-Schwartz-tól. Mérőfejekkel, mindennel. Automatizáltan le tud futtatni komplett test suite-okat.

Régóta vágyok én, az androidok mezonkincsére már!

Mit csináljak, ez a sztori éppen akkor történt, amikor az Enterprise 128-hoz vettem a bővítőkártyát. Akkor már túl voltam néhány - köztük több processzoros - mikrogép tervezésén.

Számítógép kapcsán IBM szerverekkel dolgoztam. Ha szervizelni kellett, akkor pontosan tudtam kit szabad a gép közelébe engendni, vagy kit kell megkérni, hogy konfiguráljon egy (működő) gépet. ;) Még olyan infó is volt, hogy a saját gépembe honnan, milyen gyártó ramját lehet olcsóbban megvenni.

Azt is tudom, hogy az IDE buszra sem mindig szerencsés két különböző gyártó termékét rádugni. A DDR4-nél sokkal egyszerűbb dolgok sem könnyűek. Az utolsó pc kártyát még ISA buszra terveztem, eredeti IBM AT specifikáció alapján. Gondoltam, biztosan tökéletes lesz. ;) Az elvi rajzot átadtam egy kollégának, aki spórolás céljából átrakta egy részét PAL-ba. Utána került egy másik kollégához, aki a gépparkot vizsgálta be, hogy melyik mivel kompatibilis, aztán loop. ;) Utána írtam a BIOS extensiont, amihez csak azt kellett vizsgálni, hogy melyik POST mit csinál másképp - leginkább a valódi IBM gépekben. Az utolsó lépésként elmentem könyvtárba (ilyen régen volt, az internetről sem tudtam semmit beszerezni), és az előforduló soros kontrollerek adatlapját vizsgáltam be. Érdekes módon kompatibilisek voltak, mert a beépített prioritásos interrupt kontroller egyikben sem működött az írások szerint. (Nem, nem én voltam hülye hozzá.) Végül elkészült és kiválóan működött, de azóta nem lehet kompatibilitás dumával megetetni.

Egyszerűbb házi-pécé összerakásakor meg a kompatibilitás lista alapján választok. Persze tudjuk, hogy más is mehet hibátlanul, amihez van egy tapasztalt telefonos segítségem.

A Rhode-Schwartz kütyüből biztosan kijön kettő a zsebpénzmből - hogy ne billegjen a teknő. :-D Az egyik legdrágább műszerrel a 80-as évek végén egy Dolch LA volt, amihez volt talán 4 db 64 csatornás fiókunk. Az alap gép 2MFt, a fizetésem 5500Ft volt. ;) A párja a gyártószalagon dolgozott mindenféle buszokkal a hátulján.

Nem értek az alaplap  gyártáshoz, csak tévéről hallottam. Ott az a lényeg, hogy mennyi időt tölt a gyártósoron egy munkadarab. Homályos emlékeim szerint a Videoton a franciáktól vett tévé technológiát. Ezzel talán a 3 nap vagy 36 óráról mentek le 1 nap vagy 12 órára, miközben a franciák 3 óráról 2 órára.;) Valószínűleg nagyon precíz gyártástechnológia és nagyon kitalált teszsorozat kell ahhoz, hogy a kommersz alaplapokat gazdaságosan lehessen gyártani. Nem tudom mennyi lehet egy alaplap gyártási ideje, de valószínűleg a néhány órás tesztelés nem fér bele.

A brand gépek óriási előnye, hogy koppra járatva le van tesztelve azzal a néhány alkatrésszel, amit vehetsz hozzá hivatalosan támogatottan. Lehet hogy a DDR4-4000 helyett neked csak 2933 lesz, vagy 3000, de az lesz és megy, és jön a csere gariban ha nem. A másik, hogy amit írtam, hogy ott a "downclock" több szervertípusban, ha telerakod. Ezzel sima desktopban nem találkoztam, de volt olyan, ahol ez megoldotta a problémát. Egyébként pont egy Ryzen 3900X volt 4x 32GB RAM-mal, és hiába volt a RAM HCL-es.

Több tízezer általunk gyártott, saját "brand" gépen futtattunk memtest-et az elmúlt 20+ évben. Minden egyes gépösszeszerelés után napokig futott a memtest az összes gépünkön.

Regényeket tudnék írni erről a témáról, hogy miket tapasztaltunk, mikor, mennyi idő alatt jöttek elő, vagy nem jönnek elő RAM-hibák. Hogy mennyi mindenen múlik, hogy egy stabil rendszert össze tudj reszelni.

Részben ezért nem javaslom, hogy valaki olyan terhelésre, amire Linus használja a gépét, maga hákolja össze a rendszerét, hacsak nincs haverja számos hardver boltban, aki félrenyúlás esetén cserélgetni neki az alkatrészeket.

Nem csak arról van szó, hogy különböző gyártók moduljai mások, hanem akár 100-1000-es tételben rendelt, elvileg azonos memóriamoduljaink között is voltak random bizonytalanok.

Egyszer voltam a Kingston-nál egy belső előadáson. Ott elmondták, hogy hogyan megy ez:

A legnagyobb RAM modul gyártó (mondjuk a Samsung) gyárt egy valag modult. Letesztelik, majd  minőségileg sorba állítják a modulokat.

  • A legjobbakért jön a HP, Fujitsu, Lenovo (akkor még IBM) és felvásárolja. Ezek mennek a szerverekbe, workstation-ökbe stb.
  • A maradékért jönnek a nagyobb nevű, független RAM "gyártók" és elviszik
  • A megmaradt maradékon osztoznak a kisebb gyártók
  • és ami megmarad, azt értékesítik bulk tálcás (ez általában 10-20 darabonként zöld (esetleg piros) befőttes gumival összegumizott modulokat jelent :D) formában

Ez elgondolkodtató, nem?

trey @ gépház

Persze, ezek a dolgok nem léteznek. Kár, hogy az Intel is megerősítette. A jobban sikerült CPU-kat eladták nagyobb órajelűnek drágábban, a silányabbul sikerültebbeket meg kisebb órajelűként. Nem gondolod, hogy a brand gyártó, amelyik százezres tételben veszi a ware-t elsőbbséget élvez? Vagy azt, hogy a kicsit selejtest nem adják el valakiknek? :D

trey @ gépház

Biztos letezik, hiretelen el is kepzeltem mikor a cisco, juniper es meg par masik nev a network piacon odament az intelhez, hogy akkor a felso polcrol adjon nekik valogatott intel atom c2000 cpu-kat, mert kell nekik valami megbizhato, kitesztelt fasza x86 cpu a switchekbe.

A tobbi mar tortenelem,
https://www.servethehome.com/intel-atom-c2000-series-bug-quiet/

 

Az kevés lehet ha tegyük fel Linus vásárol a gépébe új RAM-okat és teszteli maga mondjuk két napig futtatott memteszt-el?
Azért gondolom ennyit ő is megtesz a hibamentesség érdekében.

A másik ami eszembe jutott. Nem lehet hogy egy tápegység hiba is akár idő előtt ki tud nyírni alkatrészeket?

Az kevés lehet ha tegyük fel Linus vásárol a gépébe új RAM-okat és teszteli maga mondjuk két napig futtatott memteszt-el?

Ez a minimum, amit meg kell ilyenkor tenni, de ez nem garantálja a hibamentességet. A durva hibák kijöhetnek kb. 

A másik ami eszembe jutott. Nem lehet hogy egy tápegység hiba is akár idő előtt ki tud nyírni alkatrészeket?

De, lehet. Említettem is feljebb/lejjebb. 

trey @ gépház

Például tápegység hiba és tesztelés. Tesztelhetem napokig az új gépet a tápjával együtt hogy hibamentesen működik. De azt nem fogom ennyiből megtudni sajnos hogy mondjuk fél év múlva abban a tápban el fog menni egy alkatrész, egy kondenzátor és a táptól már nem korrekt áramokat fog kapni a gép.
Szóval azért a teszteléssel se lehet minden előre kideríteni.
Persze egy hibázós gépet meg el lehet vinni egészben a márkaszervizbe és oldják meg a problémát ők, adjanak vissza hibamentesen működő gépet. Amit meg persze meg kell fizetni pluszban, ha garis is akkor valahol a gép új árában.

Sőt, egy memtest futtatásával azt sem tudod meg, hogy mi van, ha a gépet 100%-on pörgeted. Komoly hibák nem egy memtest alatt szoktak kijönni. Ilyesmikre régen több szálon (make -j x), ciklusban napokig futtatott kernelfordítást használtam. Akkor még nem másodpercek voltak egy Linux kernel lefordítása, hanem akár órák :D

Volt is olyan gépem, amelyiken napokig hibátlanul futott a memtest, de egy ilyen kernelpörgetés fesztivál alatt, amikor valóban volt terhelés, összekulázta magát.

trey @ gépház

Volt olyan hogy napokig memtest egy Windows gépen, minden rendben. Később is használat közben az OS és minden program hibátlan, kivéve az Adobe programjai. Azok fagynak, hibáznak. De csak azok. Majdnem már minden csere és minden újra telepítés után RAM csere kellett hozzá hogy az Adobe programjai stabilan fussanak, de csak ahhoz, semmi más nem hibázott az eredeti RAM-okkal. Más gépben az eredeti RAM-ok hibátlanul üzemeltek később.

Gyárt ECC RAM-ot? Nem kell, hogy ECC RAM-ot gyártson. Olyan workstation-t gyártson, ami egy megbízható beszállító ECC RAM-jával tesztelten, támogatottan megbízhatóan működik.

Az a különbség a tákolt meg a supportált rendszer között (sokszor megénekeltük már a HUP-on), hogy utóbbit széleskörűen tesztelik. Brand esetén a gyártó (pl. HP) is, meg a beszállítója (pl. Hynix) is.

Ez azért más, mint amikor a sarki PC ABC összerak neked egy gépet, majd beletesz valami modult, ami kb. hozza a specifikációt, de a kutya nem tesztelte komolyabban.

trey @ gépház

Mostanában nem jártam arra. A honlapjuk működik! Bár az is komoly ráncfelvarrást kapott, mióta utoljára láttam.

Csóró középsulisként elég sok alkatrészt vásároltam náluk. Segítőkészek voltak. Volt, hogy egyik barátomnak olcsón kellett gépet fejleszteni, tőlük vettem használt alaplapot. Otthon összeraktam, nem ment, visszavittem, szó nélkül cserélték.

Jó, amikor azt mondom, hogy "PC ABC" akkor nem a létező, győri PC ABC-re gondolok feltétlen, hanem egy random PC szatócsboltra. Lehetne az a PC 1x1 is. :)

Vettem már én is náluk modult, amikor máshol nem volt. Mondjuk kellett DDR2 valahova, amikor már sehol sem volt kapható gyorsan, akkor befutottam hozzájuk és volt.

trey @ gépház

Nah, sajnos erről tudnék mesélni... Nem mostani sztori, az IBM és hírhedt Micron "feketememóriák" esete. Nem túlzok, _kilószámra_ hullottak el. Egy fiók komplett tele volt ömlesztve a hibás darabokkal.

Official IBM part volt, gyárilag azzal szállították a blade-eket. Supportált, tesztelt, támogatott. Olyan hibamódokat produkált, amitől teljesen megkergült az IBM onboard diagnosztikája is, sokszor teljesen más modult jelzett hibásnak, mint amelyik ténylegesen rossz volt. Cserélgették gariban "spot replacement" jelleggel, úgy hogy teljesen más (értsd más gyártójú, más órajelű!, más szervezésű!!), csak méretre azonos modult dugtak a hibás darab helyére. Értsd: a 8 foglalatos blade-ben maradt 7db eredeti 533MHz-es quad-rank "feketememória" és lett 1db teljesen más, tipikusan dual-rank 667 vagy 800-as, ahogy éppen adódott. Csodálkoztam, hogy azok a - memóriára egyébként híresen háklis - Opteron-ok egyáltalán megették ezt a mismatched konfigot.

tldr: a megfejtésre egyébként mi magunk jöttünk rá évekkel később, mikor már rég lejárt a gari róla és poénból szétszedtünk néhányat (építettünk belőlük űrállomást, adventi koszorút, meg ilyeneket :) ). A hiba oka az volt, hogy egyrészt a modul iszonyúan melegedett (4 chip volt egymásra stackelve egy tokozáson belül, így tudtak akkora kapacitást low profile méretben szállítani). Másrészt a hűtőborda ragasztása annyira erős volt, hogy a borda hőtágulása egyszerűen lefeszegette a szélső chipek BGA forrasztását a nyákról. És persze ez ilyen néha érintkezik, néha nem módon megőrjítette az ECC-t, az onboard diagnosztikát és persze minket is. A hibás modul gyakran attól "megjavult", ha kivetted és visszatetted, így öröm volt diagnosztizálni. Meg egy hétig hibátlanul futó memtest86 után egy kikapcs-kisvárás-bekapcs és bang már virított megint a fault led a blade-en. Ez a supportált, tesztelt, támogatott, brand gyártótól.

Régóta vágyok én, az androidok mezonkincsére már!

Melyik része milyen gyakran?

- Hogy a nagy brand gyártó benéz valamit és típushibás vagy teljesen inkompatibilis konfigokat szállít ki?

- Hogy a field service technician nem tudja (vagy leszarja), hogy a memóriákat párban illene cserélni, ha nem típusazonos a cseredarab? (Ha már le van írva a doksiban, hogy nem szabad keverni őket...)

- Hogy amikor gyártó számára is világossá válik a kiemelkedően magas hibaarány miatt, hogy valamelyik alkatrésztípus selejtes, akkor ahelyett, hogy rendesen visszahívná és kicserélné az összeset, inkább "megúszósan" egyesével cserélgeti (hadd szopjon az ügyfél minden héten) és tűkön ülve várják a garanciaidő végét, mert onnantól már nem az ő problémájuk?

Tudok amúgy HP-től is mesélni sztorikat, csak nem konkrétan memóriás témában. Többször is előfordult, hogy az általunk doksik alapján és gyártói konfigurátor toollal összerakott komplett rack-es rendelés után felhívtak minket, hogy az szerintük nem fog együttműködni, úgyhogy módosítanák a rendelést. Eleinte elfogadtuk, biztos ők tudják jobban. Aztán utána a kiszállítás csúszott-csúszott, végül a gyárból hívtak fel minket, hogy ezt nem tudják készre összeszerelni, mert nem kompatibilisek az alkatrészek... Hol volt a hiba? Persze hogy ott ahol ők belemódosítottak, végül kiderült minden esetben a mi eredeti rendelésünk volt a helyes.

A csúcs a méregdrága, talán $8000-os switchek voltak, a másik kb $8000-nyi SFP modullal. Felhívnak, hogy az általunk rendelt "A" SFP modullal nem tudják szállítani, mert azt már EU-ba nem szállítják, helyette szállítanák a "B" SFP modullal, ami tök ugyanaz. Direkt rákérdeztünk, hogy tutibiztos, hogy ez menni fog vele, mi nem látjuk a kompatibilitási listában? Persze ez hardverileg tök ugyanaz csak a "matrica más rajta", valami RoHS tanúsítvány miatt vezették be a B változatot belőle. Kiszállít, bekapcsol, persze az összes port narancssárgán világít: "error az SFP modul nem szerepel a támogatott listán, kérem csak eredeti hivatalosan támogatott HP alkatrészt használjon!" vagy valami ezzel ekvivalens hibaüzenet. Tök ugyanaz, mi?! Hosszas balhézás után (miután kiderült, hogy a latest firmware-ben sincs benne a támogatott whitelisten, és kb negyedév múlva lesz hivatalos release, amiben benn lesz) a support ránk akart sózni valami developer firmware-t, aminek a readme-je azzal kezdődött, hogy "éles rendszeren ne használd, ha telepíted, elfogadod, hogy elveszted a supportot és a garanciát a termékre". Nice try. Imádom a nagy brand vendorokat...

Régóta vágyok én, az androidok mezonkincsére már!

Hogy a nagy brand gyártó benéz

Igen.

és típushibás vagy teljesen inkompatibilis konfigokat szállít ki?

Igen.

- Hogy a field service technician nem tudja (vagy leszarja), hogy a memóriákat párban illene cserélni, ha nem típusazonos a cseredarab?

Igen.

- Hogy amikor gyártó számára is világossá válik a kiemelkedően magas hibaarány miatt, hogy valamelyik alkatrésztípus selejtes, akkor ahelyett, hogy rendesen visszahívná és kicserélné az összeset, inkább "megúszósan" egyesével cserélgeti (hadd szopjon az ügyfél minden héten) és tűkön ülve várják a garanciaidő végét, mert onnantól már nem az ő problémájuk?

Igen. 

Majd azért meséld el, hogy a hibás konfigot a gyár baszta-e el, vagy valamelyik jól sikerült "kereskedőd", amelyik baszott figyelni a warningok-ra a konfigurátorban (100-ból 100-szor ez szokott lenni), az "inkompatibilis konfig" a gyártóból jött-e vagy csak az történt, hogy rátok beszélte-e a hazai inkompetens disztribútor az általa szarul lekért konfigot, ami ott rohadt nála raklapon és rád sózta-e, hogy a field service nem valóban hozzáértő cég volt-e vagy egy kókler.

Ezeknek semmi köze ahhoz, hogy a gyártó mérnökei munkaórák ezreit fektetik abba, hogy egy konfig elkészüljön vs. Pistike a sarki áruházból weboldal vélemények alapján (ez a jobbik eset) kísérletez.

trey @ gépház

Nehéz megmondani, mert a nagyon nagy multi cég (nem akarom kidoxolni melyik volt), ahol dolgoztam, teljes céges szinten tendereztette meg a hardware supplier szerződést, amit korábban az IBM, később a HP nyert meg több évre. Vagyis a világ összes országában ők voltak a kötelező beszállító, mástól nem lehetett rendelni. A cégünk legmagasabb szinten biztosan közvetlenül a HP Inc.-el volt szerződésben, de hogy konkrétan Magyarországon volt-e valami middleman beiktatva, vagy direktben a magyar HP intézett-e mindent, azt nem tudom. Mindenesetre akikkel kapcsolatban voltam, azoknak HP-s emailcímük volt.

Az biztos, hogy nem sózhattak ránk elfekvő rosszul lekért konfigot, ugyanis nekünk volt saját referenciakonfigunk a HP-nál (ami több rendelésben már ki volt próbálva, saját QA-nk által is volt validálva), amit mi is viszonteladtunk saját ügyfeleinknek. Ebbe piszkáltak bele fogalmatlanul, nem is egyszer.

"Ezeknek semmi köze ahhoz, hogy a gyártó mérnökei munkaórák ezreit fektetik abba, hogy egy konfig elkészüljön"

Tessék parancsolni! Másik sztori, a munkaórák ezreiről...

Converged hálózat, amit a HP is egy időben nagyon nyomatott és sajnos a mi cégünkben is volt pár híve azok között, akik a referenciakonifgért felelősek voltak. A régi rendszeresített külön ethernet és külön fibre channel helyett egy kombinált általános + SAN hálózat lett. Mondjuk spórolni nem spóroltunk vele semmit, mert a hozzávaló switchek és hálókártyák annyiba kerültek, mint egy sima ethernet és a fibre channel HBA együttvéve, de ez volt a trendy, erre kellett menni. Súlyosbító körülményként kombinálva másik nagy HP-kedvenc technológiával: a VirtualConnecttel. Adott az 554FLB (sajnos egész konkrétan emlékszem erre a típusszámra) converged network adapter, ami elvileg hálókártya és storage adapter egyben. Nem pilot customerek voltunk, ez elvileg egy piacra már bevezetett, hivatalosan támogatott típus volt. Vagy 9 hónapig küzdöttünk a HP supporttal vállvetve, hogy a _supportált_ RHEL verzión képes legyen arra funkcióra, amire hivatott: képes legyen a RHEL teljesen bebootolni egy iSCSI targetről. Gyakorlatilag mi debuggoltuk ki nekik, számtalan driver, hálókártya firmware és virtualconnect firmware verziót próbáltunk végig, küldtük a trace-eket, mire sikerült összehozni egyetlen kombinációt, amivel végre működött. Annyit a HP mentségére, hogy ezt alapvetően a chipset-et gyártó OEM (Emulex - szemem elé ne kerüljön bármi termékük mégegyszer) baszta el. De ettől függetlenül egy olyan eszközről beszélünk ami előtte soha nem is tudta end-to-end végrehajtani azt a funkciót, ami az egésznek a selling pointja lett volna.

Régóta vágyok én, az androidok mezonkincsére már!

Nehéz megmondani

Érdemes lenne megkeresni a választ, mert lehetne tanulni a hibából. Furcsállom, hogy ekkora cégnél nincs ilyen szintű utóelemzése, utókalkulációja egy-egy ilyen projektnek. Főleg, ha állítólag ilyen gondok voltak vele.

Converged hálózat,

Kezdesz marha messze sodródni az eredeti témától és berángatni olyan dolgokat, ami nem csak a gyártón múlik, hanem ezer máson is. Ráadásul itt egy  Mi lenne, ha maradnának az eredeti témánál? Egy dobozon belül egy alaplap és az ahhoz gyártó által megtervezett és kitesztelt memóriamodul esete?

trey @ gépház

Ugyan más terület, de igen. Cisco 65xx típushoz szállítottak olyan line cardokat, amelyek memóriamoduljai hibásak voltak. Kellemetlen volt, mert egy egész sorozat kártya volt hibás, és mire kiderült a probléma, már üzem alatt volt az adatközpont, nem volt egyszerű megfelelő időpontokat találni a cserékhez, még úgy se, hogy a farm switchekben csak azokat a modulokat cseréltük, amelyeknél ténylegesen előjött a hiba, természetesen a core és aggregation layerben viszont mindent.

Látom nehéz ez, megpróbálom máshogy:

Tegyük fel, hogy te egy számítógép kereskedő vagy, akinek a kínálatában van saját magad által összetákolt számítógép és van az árlistádon több brand gyártó terméke is, amit a hazai disztribútorok ki tudnak elégíteni. Jön hozzád egy megrendelés, hogy kellene 1000 darab gép, amit napi 12-16 órás kb. 80%-100%-os processzor/diszk terhelésre kell méretezni.

Hogy állsz ennek neki? Hmm? Nekiállsz kísérletezgetni, öt féle alaplap, processzor, ki tudja mennyi féle memória, dobozos vagy tálcás, egy beszállítótól, vagy többtől?

Ha találtál egy olyan konfigot, ami elindult, meddig fogod tesztelni, hogy meg merd rendelni az 1000-1100 alaplapot (ráhagyással, mert mi van van közte rossz/bizonytalan), elbaszod véletlen összeszerelés közben stb., az 1000-1100 CPU-t, fasz tudja mennyi memória modult, tápot (Vargáné és társa ne legyen közte!) ... Aztán öt évig megy majd az activity, hogy tfh. az ország ezer részére leszállított 1000 PC garanciális nyűgjeit supportálod. Tarts rá egy 2-5 fős technikus brigádot autóval mindennel. 

Hmm?

Vagy leadsz rendelést 1020 darab brand workstation-re, amit megterveztek, kiteszteltek, összeraktak, leszállítottak, supportálnak és onsite garanciában még a javítást is megoldják az 5 év alatt.

Te melyiket vállalnád be?

Hagyd is a számolgatást, mások már kiszámolták helyetted. A tákolt PC ipar gyakorlatilag megszűnt a 20 évi mennyiségekhez képest. 20 éve még építettünk évi sok ezer PC-t, manapság ez visszaesett évi néhány százra. Vegetál.

trey @ gépház

Nehéz, mert én mindössze válaszoltam egy kérdésedre, hasonló területről. Neked nem tetszett a válasz, mert - bár nem pont az a terület - de pont nem azt támasztja alá, amit te szerettél volna mondani. Ezek után teljesen más témáról kezdesz el beszélni, ami engem speciel nem érdekel. Szóval  inkább ne próbáld meg máshogy, mert az csak terelés.

Mert minek hívjam azt, hogy

  1. Gépet akarok venni, felütöm a Phoronix-et, Tom's Hardware-t, ... és megnézem mi szerepel a benchmarkokban jól
  2. Mondanak valami CPU típust meg alaplapot, beütöm a helyi árgépbe -> legolcsóbb helyről|ahol van éppen raktáron megrendelem
  3. Kéne bele valami memória, véletlen sem nézem meg, hogy mit ajánl bele a gyártó, rendelek valamit, ami gyorsan megjön, rábaszok egy éjjel futó memtest-et és kijelentem ez OK

Kb. ez a szint, amit Linus csinált.

Ez orosz rulettel egybekötött tákolás. Nevezhetnénk még PC-skedve homebrew rendszerépítésnek is, de kb. ugyanazt jelenti.

De, ugyanez a szint a "hama'gyorsan ugorj Pisti, kérdezd meg az Ingram|Rufusz|HRP|Whatever éppen milyen szarjuk van raktáron, ja, hogy nincs ... van az az izé beragadva ... várjá', mingyá befoglalom, ja nem főni, elvitték ... akkor rendelj az Ingramtól 200 ilyet, a Feri autóba pattan, kimegy Pozsonyba|Bécsbe, hoz ezt, te menj, hívd Romániát .."

Kérlek :D

Ebben az iparban vagyok 20+ éve. Tudod miket láttam? Mindent is. :D

EZEK TÁKOLÁSOK.

trey @ gépház

Ez nem a tákolás. Ez a power user kategória, és örüljünk neki, hogy létezik.

A tákolás a csokival összetoldott UTP. Az tákolás. Meg ami képek itt fent voltak a már nem is tudom milyen nevű topicban :D

Persze, nem ezzel kell egy 1000 fős céget ellátni. Nálunk ~200 körül is már csak brand gépeket vesznek. Amikor egyszer valakinek kellett volna nagyon erős GPU-val valami, ami brand-ben 3x annyiba került mint ha építették volna, az IT akkor is nagyon-nagyon a brand gépet javasolta. Pedig régen ők is építkeztek.

 

Más kérdés, hogy a mai PC piac már messze nem annyira releváns, mint 20 éve. És a relevanciát nem abból a szempontból értem, hogy mekkora a piaci részesedés, hanem abból a szempontból, hogy mennyire kell egy konfigot egyénre szabni.

Általában azt szoktam mondani, hogy otthonra minek egy micro ATX-nél nagyobb alaplap? Úgyse tesz bele senki semmit, max. egy videókártyát. Sokszor azt sem. A multi GPU is nagyon ritka.

De semmilyen speckó periféria nem kell ma egy PC-be. Az is vicces, hogy van egy mai alaplapon minimum 6 SATA port, aztán a PC házak túlnyomó többségébe már front panel kivágás sincs semminek. Se optikai meghajtó, se kártyaolvasó, semmi. És általában egy NVMe slotnál nem is kell több.

Legyen egy db. LAN port, ritkán kellhet kettő, legyen sok USB, meg min. 2 HDMI/DP, és csókolom. RS-232 még itt-ott ritkán előfordul (de azt is lehet USB-re akasztani), párhuzamos már rég kihalt, modem hála az égnek ~20 éve nincs, igazából a 3.5 jack helyét is lassan átveszi az USB, az S/PDIF pedig sose volt nagyon elterjedve.

Ami esetleg ipari PC-ben kell plusz IO, azt meg már úgyis mindenféle ethernetes meg néha USB boxokba szervezik ki.

Processzorból is felesleges szerintem ekkora palettát tartani, igazából elég lenne egy kicsi, egy közepes meg egy nagy. Persze a választék egy része chip harvest, azt kidobni mondjuk kár lenne. Ezentúl semmi customizálás.

Még olyan szinten sem, hogy pl. kapsz SLC SSD-t? Már az MLC is ritkaságszámba megy. MRAM, FRAM hasonló egzotikus technológiákról ne is álmodjunk.

Ha munkához kell, akkor a kitesztelt hardverkombináció, frissítések, helyszíni / csere gari fontosabb szempont, mint az, hogy 10 ponttal többet hoz 3d markban 20 forinttal olcsóbban. 
Ha valami egyedi igényre nincs brand megoldás, vagy túlságosan extrém árú, akkor előfordul, hogy barkácsolnak. Azt is tudván, hogy ez plusz kockázat / munkaidő. 

Az, hogy sok helyen azt látod, barkácsolnak, az nem magyar virtus, hanem csóróság. Nem futja munkára készített eszközökre, viszont jóska-pista minimálbérért majd "megoldja" okosban. 
Az, hogy otthon számítógép építés a hobbid, az teljesen irreleváns a munkahelyi számítógépek kapcsán.

Ez rendben, csak azt döntsük el, hogy Linusnak ez munkaeszköz vagy játék. Én az utóbbira hajlok, de elfogadok másféle értelmezést.

Hint: munka az amit az ember a megélhetésért csinál, ahol azt kell csinálnod amit a főnök/megrendelő akar, mások osztják be az idődet és alantasnak, megalázónak, értelmetlennek érzed. Szerintem Linus ebből egyiknek sem felel meg :)

Van igazság abban, amit írsz, de én nem temetném a PC-s ipart. Igen, a mérete a klasszikus aranykorhoz (80-90-es évek, meg a kora 2000-es) csökkent, mivel lassul le a fejlődés, meg a legtöbb embernek ma már csak telója, táblagépe van, és beérik azzal, de azért továbbra sem haltak ki a PC-k, kormányzati szervek, cégek, oktatási intézmények, szolgáltatók, stb. még mindig intenzíven használják, meg sok szakma (fejlesztő, grafikus, videószerkesztő, írói, adiminisztrációs, stb.) is ezen alapul még mindig, illetve hiába a konzolok, a játékpiacnak is még mindig jelentős szelete. Így a PC-k mindig is fognak fogyni, mert a régi is hiába nem avult el, tönkremehet, nem upgrade-elhető gazdaságosan már, vagy szoftveresen van mesterségesen elavultatva (ala Win11).

Elvileg ma is bármelyik SSD használható SLC módban, ha a firmware-jét meg tudod patkolni. Ugyanis a SSD-kre forrasztott Flash NAND chip az nem akármilyen LC föggő, használhatod bármilyen módban, tőled függ, hogy egy cellában hány bitet akarsz tárolni. Nyilván, ha SLC módban használod, akkor egy TLC-hez képest 8-ad akkorára csökken a kapacitása, de cserében a sebessége nő, simán lehetséges.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A consumer részen valsz olyan, mint bármi más gyártó, ahol az éppen olcsón kapható alkatrészekből havonta jön ki újabb kombináció.
Az üzleti részen sokkal korlátozottabb, hogy milyen alkatrészt használnak. Azokból 5 évig alkatrészeket is kell raktározniuk és addig rendszer fw updateket is kiadniuk, ahogy kiderülnek hibák. 

Az összeszerelő üzemben sima futószalagos melósok vannak. Plusz a standardizált teszt eszközök, amelyekkel a készülékeket letesztelik. Nem sysadmin god géza ül a sor végén, hogy memtesztelje az elkészült példányokat. A szakemberek ott ülnek, ahol a standardizált teszt folyamatot kialakítják.

Laptop vonalon például a thinkpademre 7 évig jöttek ki fw frissítések, hogy kompatibilis legyen az win10 verziókkal is. Ez tényleg szerencsés belenyúlás volt, mert általában 5 évig támogatottak. Az új asusomra meg fél évig jöttek ki frissítések, valsz többé nem fog jönni, azóta már a 20adik hardverkombináció változatnál tarthat a széria. 

Arra a feltételezésre építesz itt, hogy a brand gyártó semmi egyebet nem csinál, mint fog standard alkatrészeket, összeválogatja, összeépíti, az egészet QA-zza, és eladja.

Sajnos a brand gyártók nem csak ezt csinálják.

Beletesznek proprietary fejlesztéseket.

Ezek egy része "value added" lenne az ügyfélnek. Ehhez általában kapsz egy windows-os drivert és utility-t előtelepítve. Szerencsésebb esetben mondjuk valamilyen nagyobb brand linux disztróhoz (pl RHEL) kapsz egy binary-only drivert és utility-t. Mondjuk ezzel tudod monitorozni, hogy van-e ECC hiba, vagy mi a RAID tömböd health státusza, mi van a firmware és onboard diagnosztika logjában, remote manage-elni a gépet stb.

A fejlesztések másik része már nem kifejezetten az ügyfél érdekében van. Ezek a hardveres DRM-ek: a memória, PCI kártya, SSD whitelist-ek, hogy esélyed se legyen mástól venni alkatrészt a gépbe. Hasonlóképpen vannak a szabványtalan méretű tápegységek, szabványtalan bekötésű tápcsatlakozóval. Persze, tudom, meg kell védeni a felhasználót attól, hogy a pénzét másnál költse el, nem supportált alkatrészekkel rontsa el a gépét. Ha pénz nem számít, akkor be tudsz szerezni alkatrészt a vendortól... amíg a support periódus le nem jár. Meg amíg a vendor saját supportált alkatrészei a vendor saját DRM-jének hibájában hasra nem esnek. Utána, jön az ebay-en vadászás a leselejtezett donorgépekre, meg bontott alkatrészekre. Ez is egy műfaj...

És akkor jön a leginkább ügyfél-ellenes kategória, a sunyi telemetriák, hazatelefonálások meg firmware-be égetett levakarhatatlan backdoor-ok és konkrét malware-ek (ugye emlékszünk, mikor a Lenovo UEFI payloadból fertőzte vissza Superfish-el a friss windows újratelepítéseket is...)

Sajnos ezek a vendor-specifikus technológiák tapasztalatom szerint ritkán kapnak elég alapos QA-t (legalábbis a komplexitásukhoz mérhető alaposságú QA-t), és a zárt dokumentálatlan jellegük, valamint a korlátozott install base miatt szépeket lehet szopni velük. Én azt gondolom, legalább annyit ártanak, mint amennyit nyersz azzal, hogy az alap-alkatrészek össze vannak tesztelve. Ha össze vannak, és nem véletlenül egy olyan konfigba nyúlsz bele, amit a QA egyáltalán nem is látott...

Régóta vágyok én, az androidok mezonkincsére már!

Beletesznek proprietary fejlesztéseket.

Ja, ezt most úgy mondod, mintha a polcról levehető alaplapgyártók mondjuk az open source driverek éllovasai lennének. :D Azzal, hogy te legózol össze dolgokat, nem sokkal vagy előrébb. Ráadásul, ha Linux megy rá, nem tudom milyen jelentősége van itt a windowsos drivereknek. Sem én, sem Linus nem Windows használ a gépén.

trey @ gépház

Nem úgy mondom. Azért ne vonjunk már egyenes párhuzamot aközött, hogy az ASUS saját fejlesztésű IC-je miatt oprendszerből nem tudod állítani a ventilátor fordulatszám-profilt (csak BIOS-ból) és nem tudod ritmusra villogtatni az RGB ledeket. Meg aközött, hogy a brand vendor de facto backdoorozta a gépedet valami "anti-theft" és "enterprise remote management" feature keretében. Meg, hogy eFuse kiégetéssel összepárosítja a processzort az alaplappal és ha bármelyiket cserélni kell, akkor mindkettő kuka (lásd újabb Lenovo Thinkcenter-ek), természetesen ez is, mint mindig, a "Te biztonságod érdekében".

Egyébként pl Supermicro alaplapokkal valahogy nem szoktak ilyen problémák lenni, mikor nekem dolgom volt whitebox - a te szóhasználatoddal élve: "tákolt" - szerverekkel, valahogy Linux alatt minden hardver standard volt, és minden out of the box működött. Ja és 10+ évig mentek hiba nélkül.

Régóta vágyok én, az androidok mezonkincsére már!

"Utána, jön az ebay-en vadászás a leselejtezett donorgépekre, meg bontott alkatrészekre. "

ha már lejárt a szerződött X év támogatás, akkor már a saját felelősséged, hogy miért használsz támogatás nélküli, régi eszközöket. Van olyan cég méret, ahol megéri saját részleget fenntartani erre, de azoknak lehet a gyártást is egyedi igény szerint csinálják. Amúgy nem véletlen, hogy használt gép vásárlásakor is inkább használt üzleti gépeket szoktak ajánalni, nem pedig mindenféle kókány barkácsot vagy akár több éves consumert. 

Ha leselejtezett eszközöket veszel, akkor ne csodálkozz, hogy nincs rá támogatás. Az élettartama alatt a gyártó által bevizsgált kombinációk támogatottak, az hogy gányolni akarsz, nem támogatott. Valahogy mindig ott kötünk ki, hogy a csóró magyar cégek alapján képzelitek el a komolyabb cégek működését.

Persze van az a műfaj is, hogy a céges IT a különféle ISO meg hasonló compliance dolgok miatt kötelezően selejtezi és cseréli az összes hardvert, amint a gyártói support lejár rá.

Csak ugye itt most Linus saját fejlesztőgépéről van szó, nem pedig valami nagy céges IT-ról 1000+ laptoppal, meg munkaállomással. Nyilván egy céges IT-nak teljesen mások a prioritásai. Remote felügyelni meg policy-kből korlátozni akarják mit csinálsz a gépeden, egységesített, megváltoztathatatlan szoftverkörnyezetet tartani a gépeken stb. Amit Linus csinál, az "picit" kimutat ebből a témakörből.

Mindenki azon siránkozik, hogy mennyire károsan corporate lett a Linux fejlesztése, most meg az a probléma, hogy nem eléggé corporate?

"Ha leselejtezett eszközöket veszel, akkor ne csodálkozz" - az ok okozati sorrend fordított volt a mondanivalómban. Ha akarod használni a gyári support perióduson túl is a korábban rendesen beszerzett vasadat, akkor rákényszerülsz, hogy leselejtezett alkatrészt vadássz hozzá.

"Valahogy mindig ott kötünk ki, hogy a csóró magyar cégek alapján képzelitek el a komolyabb cégek működését." - Nem akarom megnevezni a volt munkahelyemet, de a világ több országában van jelen, mint amiben nincs. Bizony ott is beüt a baj, mikor jön 1-2 rossz pénzügyi eredményű negyedév, vagy egy nagyobb felvásárlás miatt átmenetileg rossz a cash flow és hirtelen már élesítik is a company-wide beszerzési tilalmat. Meg élt az elvárás, hogy az egyes product line-ok önmagukban is legyenek cash-flow pozitívak. Nyilván amíg nincs fizető ügyfeled egy új termékre, addig nincs hardver-beszerzés sem, pech ha konkrétan olyasmivel foglalkozol (cloud management), amihez kellene dedikált vas. Amíg ott voltam, a mi csoportunk konkrétan 3 terméket fejlesztett ki 0-ról úgy, hogy a fejlesztőkörnyezet szinte teljes egészében más (cégen belüli) részleg selejtezésre váró hardvereinek átvételéből épült fel. Nagyon a vége volt, mire kaptunk engedélyt új beszerzésre. Szóval nem, ez nemcsak a csóró kisvállalkozások sajátja.

Régóta vágyok én, az androidok mezonkincsére már!

Valóban összemosódnak a dolgok. Mert onnan indultunk ki, hogy miért nem vesz rendes üzleti munkaállomást a linux kernel atyja, ha rá vár mindenki, amikor szar a gépe. 

A többi körítés már azon rángatózás, hogy rendes munkaeszköz kell -e olyan munkához, ahol számít a megbízhatóság vagy sem. Van aki szerint szarból lehet a legjobb várat építeni, mert mindig úgy szokták. Más szerint meg, ha elég komoly a téma, akkor arra pénzt is kell költeni és megfelelő felszerelést venni. 

mert lehetne tanulni a hibából

Én pontosan tudom mi a hiba. X évre előre egy cégnek odaadni az összes megrendelésedet. Pont ugyanaz, mint állami szférában a központi közbeszerzés. Ha egyszer meg van nyerve, onnantól hátradőlés van, mert X évig nem lehet kigolyózni a beszállítót, hacsak valami ordasnagy gazemberséget nem csinál.

Kezdesz marha messze sodródni az eredeti témától

Szuper! Akkor térjünk vissza a cikkhez. Linus beszopott valahány correctable ECC hibát, erről szólt a posztja. Kicserélte a hibás modult és minden megy rendben tovább. Fogalmunk sincs róla, hogy ez attól volt-e, hogy a inkompatibilis alkatrészekből tákolt gépet használna. Vagy egyszerűen beszopott egy random egybites cellahibát, ami minden alkalommal bejelzett, amikor ráolvasott a konkrét címre. Ennek ellenére Te elkezdted abba az irányba "elsodorni" a témát, hogy miért nem brand gépet használ. Van bármi konkrét infód amiből lehet arra következtetni, hogy Linus ténylegesen inkompatibilitás miatt szívta be ezt a hibát?

Régóta vágyok én, az androidok mezonkincsére már!

Linus beszopott valahány correctable ECC hibát, erről szólt a posztja.

Nem, nem erről szól. Arról szól, hogy összetákolt egy gépet, amiben beszart a memória, Rendelt az internetről valami memóriát, ami 10 hónap után (? - vagy csak most vette észre?) megint cserére szorult.

https://lkml.iu.edu/hypermail/linux/kernel/2210.1/00691.html

Most megérkezik valami, ami vagy jó lesz vagy sem. Vagy jót rendelt, vagy sem. Vagy jót szállítottak, vagy sem.

Az egész egy lutri.

trey @ gépház

Mondjuk, mire ne lenne elég egy HP Workstation Z8 G4/G5 Tower

  • 2x Intel® Xeon® Gold 6258R (2,7 GHz-es alapfrekvencia, Intel® Turbo Boost technológiával akár 4,0 GHz, 38,5 MB L3 gyorsítótár, 28 mag)
  • max. 3 TB RAM
  • NVIDIA RTX™ A6000 (24 GB dedikált GDDR6)
  • up to 2TB SSD
  • rendes tápegységek

Link: https://www.hp.com/hu-hu/products/workstations/product-details/product-…

trey @ gépház

Ő rakta össze:

In fact, the biggest excitement this week for me was just that I
upgraded my main machine
, and for the first time in about 15 years, my
desktop isn't Intel-based. No, I didn't switch to ARM yet, but I'm now
rocking an AMD Threadripper 3970x. My 'allmodconfig' test builds are
now three times faster than they used to be, which doesn't matter so
much right now during the calming down period, but I will most
definitely notice the upgrade during the next merge window.

És "fejlesztgette":

And yes, my system is all set up for ECC - except I built it
during the early days of COVID
when there wasn't any ECC memory
available at any sane prices.

Általa rendelt alkatrészekkel:

Right now I'm doing merges (very slowly) on my laptop, while waiting
for new ECC memory DIMMs to arrive
. [...] My new memory is "out for delivery", so hopefully I'll be back up to
full speed by this evening

trey @ gépház

Kombikazán savazás :D Na az is 1 szép meló lehet.

Aztán vagy olyan a hőcserélő kialakítása, hogy van értelme, vagy sem. Utóbbi esetben a fasz szerelő ugyanúgy elszedi azt a 30-40 ezret (ma 2023-ban nem tudom hol áll perpill) holott jól tudja h. nem fog segíteni, mert olyan kacskaringós a járat h. nem fogja tudni mindenhonnan kiszedni a vízkövet alaposan. Legalábbis mikor azt az átkozott buderus-t akartam volna kisavaztatni 3 éve, megkérdeztem 2 szerelőt, mindegyik csak húzta rá a pofáját. De legalább nem hitegettek, mai világban már ez is értékelendő. Vagy csak nem volt kedvük szopni vele azon a héten, mert volt jobban tejelő melójuk. Ugyebár hasznos tudni az ellenség fejével gondolkozni.

tenyleg a sarki fuszeresnel osszevalogatott gepet hasznal?

Nekem valahogy szimpatikus.

Egyrészt a Linux eredeti küldetése alapján eleve amolyan sarki fűszeres operációs rendszer, ami rengeteg felhasználónál sarki fűszeresnél vett gépeken fut.

Másrészt meg azt gondolom, hogy ha egy ilyen kaliberű ember ennyi pénzből is képtelen összeválogatni egy működőképes hardvert, akkor nagy a baj.

  1. Sarki fűszeres operációs rendszer volt kb. 15-20 éve, ma már - tekintve milyen széles körben használják - nem az
  2. Senki sem mondta, hogy a jó szoftveres egyben jó hardveres is.
  3. A széles körű tesztelést nem helyettesíti az ember kalibere, amit Linus most csinál, azt úgy hívják, hogy "élesteszt". Éles körülmények között tesztelget random hardvereket. Ez el is megy sok helyen, de amikor az ember ideje drágább, akkor nem ez a jó irány.

trey @ gépház

Nekem gyanús, hogy a 3000-es Threadripper széria (ami egyébként papíron workstation) még nem vagy "csak bizonyos gyártókkal" ette az ECC RAM-ot. Jellemzően az AMD nem tiltja az ECC-t, viszont ha nincs hivatalosan támogatva, akkor mindenféle előfordulhat. A másik dolog, hogy ha tökig rakta az alaplapot, akkor előfordulhat, hogy vissza kell venni a frekit egy fokkal. Nem, ez nem AMD sajátosság, tessék végignézni néhány szerver manuált, hogy ha minden dimm slot belakott, akkor bizony visszavételre kerül a freki.

Ami nekem fura: hogyhogy nincs a linux mögött egy build cluster CI/CD integrációval. Én is szeretek gépet építeni, de azért A LINUXNAK csak kijárna egy. Igaz, nem akkora a forrás, hogy ne lehetne értelmes idő alatt akár laptopon is fordítani.

Meg aztán clustert építeni még jobb móka lehet, mint egy gagyi threadripper konfigot. Nem véletlenül ki is vezették. Akkor már inkább EPYC-be kellett volna beruházni.

Trey keze alatt nincs 10k+ mennyiségű fizikai szerver nagy valószínűséggel. Habár pályafutása során megfordulhatott ennyi fizikai szerver a keze alatt.
Magyarországon nagyon kevés ember van, aki 10k+ fizikai szervert kezel egyszerre akár hardveresen, akár szoftveresen.

10k+ gépnél már tudsz egyedi árat kérni egy testreszabott konfigra. :) Egyébként szerver RAM hibára, akár csak simán ECC-sre az elmúlt 20 évben errefelé nemnagyon volt példa. Nem mondom, hogy nem fordult elő, ahhoz képest ahány gépre rálátok talán ha 2-3 évente fordul elő 1-1 modulhiba. Szerintem RAM modulokból bőven 100-as nagyságrendről van szó.

100-as nagyságrend (csak az egyik partnernél van legalább 100-150 modulnyi RAM), de most biztos nem fogom összeszámolni. Igen 12-16 modulos gépek, jellemzően virtualizációval, szépen megtöltve a RAM-ot. Ha olyan sűrűn halnának, akkor ebben a relatív kis mintában jóval többel kéne szerintem szembesülnöm szerintem. Ez természetesen az aktuálisan futó masinákban van, azért az elmúlt 20 évben nem 1-2 géppel volt dolog, vagy legalábbis rálátás.

Nyugodtan mondhatom, hogy több ezer brand szerverhez volt közöm, memóriahibát a 20+ év alatt felidézni sem tudok, nem hogy tömegesen fordult volna elő.

Ott, ahol tömegével hullanak a memóriák, elgondolkodnék, hogy mitől:

  • szarul megtervezett rendszer
  • DIMM-ek nem szakszerű szállítása, tárolása, kezelése, beépítése (antisztatikus szerelési környezet, technológiák be nem tartása stb.)
  • nem megfelelő modulok használata (elindult vele, jó!)
  • hűtési problémák
  • stb.

trey @ gépház

Ugye annak az IBM Bladecenter-nek RAM hullását szakszerűen és gyorsan (tippelem: onsite, 4 óra, mérnök jött, hozta, cserélte, megírta munkalapot és készen volt) megoldották? Nem kellett totózni, hogy mit kéne helyette venni, végső soron megoldódott a probléma és 10 hónappal később nem kezdődött elölről egész?

trey @ gépház

Mivel nem velem esett meg a tömeges RAM-halál - csak idéztem -, így a kérdést nekem feltenni elég nagy ostobaság.
Nálunk momentán egy BlackRAM esett el, így abból én nem vontam le messzemenő következtetést. A BC fogyasztásából annál inkább.

Ja, olvastam a terelést. Rákérdeznél erre mitikus RAM-halálra ami a BladeCenter-eket érintette, hogy mi lett végül a megoldás? Kísérleteznek vele még mindig, mint Linus (akinél majd csak az idő/szerencse dönti el, hogy a mostani RAM-cseréje megoldotta-e a problémát)?

trey @ gépház

Te dolgod mit gondolsz, leírtam hogy lesz*rom. Te tapasztalat nélkül akarsz észt osztani.  Vagy talán van _folyamatosan_ 10+ szerver üzemeltetése a kezed alatt, hogy tudd milyen napi problémák vannak vagy sem? Ha nincs, akkor ne tegyél ilyen generikus kijelentéseket, mert nincs igazad. A memória csere napi jelenség, nem köthető sem szériához sem gyártóhoz. Ha van hibás széria, akkor arra ilyen méretben elég hamar rájössz. 

Vagy talán van _folyamatosan_ 10+ szerver üzemeltetése a kezed alatt

Ennél azért jóval több van, willy :D

A memória csere napi jelenség, nem köthető sem szériához sem gyártóhoz. Ha van hibás széria, akkor arra ilyen méretben elég hamar rájössz. 

Zavarj számokkal, gyártóval, típussal. Pls.

trey @ gépház

Ha eddig nem fogtad fel, hogy ilyet tőlem nem fogsz kapni, akkor valami nagy gond van...

Annak az oka pedig hogy nem mondom, nem csak az lehet, hogy nincs adat.  A fenti részben arra próbáltam rámutatni (sztem kedvesen) hogy ami véleményed  "jó memória, jól összerakott gép, jó körülmények" pedig csak elméletben állja meg a helyét és a nagy számok skáláján elbukik. 
 

Legyen itt adat is azért: a memória meghibásodások száma a CPU meghibásodások 3. magnitúdóján van, és kb egy magnitúdón van alaplap/bmc hibák nagyságrendjével.

Egy fejlesztőnél szerintem természetes, hogy ilyen dolgok adódhatnak. Ha megvenné mindenből a legjobbat, vagy csak a gyártók által javasolt holmikat hegesztené össze, akkor a fejlesztésből pont kiesik az a laikus átlagfelhasználó, aki bontókból összekapart gépein futtat linuxot.
Szóval a fejlesztőnek látnia kell a barkácsolótól kezdve mindent.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Csendesem megjegyzem neves gyarto, idei évben tobb tucat szervereben mar szamos ecc ram cseren vagyunk tul.

Pont az a lenyege kap egy kis napszelet es szol, de akkor is ha "elfaradt" . Bosszanto de meg mindig jobb mint egy hibas eredmeny.

Fene tudja miket íratnak alá. Voltam olyan workshopon, ahol az előadó nem mondhatta meg a nagy gyártó nevét, csak annyit mondhatott, hogy "High Price" :)

Vagy ami azt hiszem itt is volt korábban téma, hogy pl. SQL szerverek benchmarkját nem hozhatod nyilvánosságra (Oracle, MS).

És a legtöbb munkaszerződésben mintha benne lenne, hogy a cég jó hírnevét sem sértheted meg.

Nem értem. Nekem gyanús, ha egy gépben túl gyakran megy tönkre a RAM, ott gondolni kell rá, hogy nem csak a RAM-okkal van baj, alaplap, táp, stb. mind ludas lehet, Linusnak is ezt tudnám tanácsolni.

Esetleg arra tudok gondolni, hogy Linusnál be van kapcsolva a BIOS-ban az AMD procikhoz való PBA mód, ami lényegében egyfajta gyári boost frequency overclock, és emiatt hibáznak a memóriái, vagy túl agresszívra vette a memória időzítéseit.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Az PBO, én emlékeztem pontatlanul a nevére. Tippelem csak, hogy összefüggésben lehet a problémájával.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Esetleg még azt tudom elképzelni, hogy Linus procijában marginális a memóriavezérlő, ritka, de előfordulhat. Nem mondom, hogy ez is teljesen tuti tipp, de én ilyen fronton is nézelődnék a helyében, CPU/PBO fronton, esetleg RAM hőmérsékletét figyelni, végső esetben VRM probléma, hátha rájön hol a bibi, és nem kell x havonta új szett memóriával szopatnia magát.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem szeretném, de az egyik piacvezeto.

Neha aggodom, hogy oregszem, de mindig megnyugtat, amikor arrol olvasok, hogy masoknak is kihagy a memoriaja. :-)

Örök életet, ingyen sört és szoftveres ECC-t a Linux kernelbe! :D

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Nem ez a probléma, hanem hogy a BZD 08-as alaphoz a XYZ 04-es biszbasz tuti jó lesz-e, és hosszú távon. Simán bele lehet abba futni, hogy mondjuk néhány hétig jól megy valami, aztán kijön valami marhaság. Nekünk még a DDR2 vonalon (kevésbé szerverrel) volt olyan, hogy hiába teszteltük a RAM-okat egy alaplapban, ott csak 36+ óra után dobott hibát, amiben meg néha hibázott, ott SATA hibák jöttek... Olyanba is futottunk bele, hogy a neves RAM gyártó által konkrétan brandgyártó gépéhez mondott RAM modul mégsem ment abban a csoda gépben (intel i3 szuper entry szerver wtf....), CSAK a saját brandje. Szal vannak vicces dolgok, és a régi Intel SHG2 + DDR1 Reg ECC dolog még csak épp eszembe jutott. :)

És mindez mit befolyásol abban, hogy egy hw buzi bemegy-e összerakatni a confot a sarki pcshez? Meg nem annyira értem, miért gondoljátok, hogy neki se fingja sincs, se olyan ismerőse, akinek van fingja? Meg hogy ha véletlenül belenyúl nem szarja e le, azt cserél. Kissé túlmisztifikáljátok ezt a sztorit. 

De nem azt csinálja, hogy elmegy a sarki PC-shez és összerakatja, hanem rendel a netről valamit és maga összerakja.

Egyébként korlátozott árukészlettel rendelkező sarki PC-snek sincs meg feltétlen az a tapasztalata, ami mondjuk megvan egy OEM System Builder-nek vagy brand gyártónak.

trey @ gépház

Biztos tudják, hogyne tudnák. Itt pusztán arra próbáltam már sokadszor rávilágítani, hogy tetszőleges szuperszaki (Linus esetben ténylegesen az) lehetsz, de a konkrét mennyiségi tapasztalatod egyszerűen ettől még nem lesz meg. Ahogy írtam nekem van kollégám aki ha nem is napi szinten, de rendszeresen high-end desktopokkal foglalkozik, és ha ilyen igényem lenne akkor őt tuti meg kellene kérdeznem, hogy mi a helyzet. Gondolom, hogy hasonlóan tett Linus, és ennek ellenére belefutott valamilyen alkatrész problémába.

A B opció, hogy fogta megnézte a HCL-t, és jóhiszeműen rendelt, ami egyébként teljesen jogos elvárás, hogy mennie kéne. Ugyanakkor pont ECC RAM és a Threadripper nem tudom mennyire hivatalosan együttműködő a "bolti" alkatrészes vonalon. GKH gépéről már szerintem linkeltem. :)

Itt pusztán arra próbáltam már sokadszor rávilágítani, hogy tetszőleges szuperszaki (Linus esetben ténylegesen az) lehetsz, de a konkrét mennyiségi tapasztalatod egyszerűen ettől még nem lesz meg

Ezt értem, de én ilyet nem is állítottam, én csak arra reagáltam, hogy Linus (vagy kb bármelyik ilyen hw geek) nem fogja akarni kiadni a specet, hogy építsetek valamit egy ilyesmi cégnek. Ha ezt akarná, akkor megvenné valami brandtól az összerakott brutál gépet, aztán szevasz.

"és ennek ellenére belefutott valamilyen alkatrész problémába"

Egyébként tudjuk ezt, hogy tényleg ez történt? Mármint kompatibilitási hiba miatt voltak az ECC errorok? Mert azon túl, hogy trey bedobta ezt a gumicsontot, az eredeti posztból nekem ez nem derült ki. A leírtak alapján simán lehetett egy egybites cellahiba is, azt pedig semmilyen kompatibilitási lista nem segít megelőzni. Sőt a correctable ECC error nekem kifejezetten arra utal, hogy nem valami signal integrity probléma volt, ami sok random hibát csinál (ott komoly esély van, hogy több bit is egyszerre hibás lesz), hanem valami izolált hiba.

Régóta vágyok én, az androidok mezonkincsére már!

Pont a napokban olvastam cikket, hogy a gyártók használt memória modulokat használnak fel új modulok gyártásakor, de ha jól emlékszem 2400MHz-ig kell óvatosnak lenni. Kerestem a magyar cikket de nem lelem.
Valakinek nem rémlik?

a kínai noname / hamisítvány gyártók szoktak bontott szerver modulokból építeni desktop modulokat. Onnan ismerni meg, hogy brandtől függetlenül mindnek ugyanaz a nyákja.

Plusz régebben voltak a high density chipek miatt "amd only" modulok is alin, mert a nagy kapacitású chipeknél egy bittel hosszabb cím kell, amit desktopon nem támogatott az intel akkoriban. Ddr2 -ből nekem is van ilyen. De tlaán ddr3 is volt hasonló. Amúgy olcsó, szedett vetett gépbe ettől még jó lehet netezni.

Hasonlóképpen kapni alin szerver chipsetes microAtx alaplapokat is, régi xeon procihoz.

Simán lehet szopó némelyik kombinációval.

Nem láttam leírva, hogy pontosan milyen a konfigja. Mostanában például asus lapok körül volt botrány, hogy megsütnek procikat bios bug miatt. A memóriavezérőnél fesz állítsá is süthet memóriát, ha bugos. Meg a már emlegetett tápegység vagy más probléma. Esetleg a nagyi uránfestékes cserépedényét el kéne venni a gép tetejéről.