Het grote zuinige server topic - deel 3

[croque_monsieur]

Bij ibecc wordt 1/32ste deel van het geheugen gereserveerd voor de ecc informatie. Terwijl bij unbuffered ECC een chip extra is. Dus ipv 64bit bus heb je 72bit, dat is 8 bits aan ECC informatie per 64 bit aan data.

Waar ik bang voor ben is dat bij IBECC minder fouten kunnen worden gefixed dan bij normaal ECC. Er zijn minder gegevens voor de error correction.

[Mars Warrior]

Jerie schreef op donderdag 23 juli 2026 @ 09:42:
[...]


Bitrot. Of niet. Je weet het niet.

Want?

Als SnapRaid in 10 jaar bij mij nog nooit een fout heeft gedetecteerd, dan heb ik blijkbaar tijdens de controle in RAM nog nooit een bitflip gehad, immers anders zou SnapRaid toch herhaaldelijk (onterecht) moeten melden dat een bestand corrupt is geraakt.

Aan de andere kant toont dit van geen kant aan dat ik nooit memory fouten heb

Maar als RAM zonder ECC echt waardeloos zou zijn, dan zou ik ELKE dag bitflips hebben en dan zou de SnapRaid-log toch volstaan met fouten, want de scrub loopt elke dag.

Besef ook dat mijn server met gewoon DDR5-geheugen 60 containers draait die elke minuut encrypted data van Azure verwerkt. Daarin zit naast de encryptie ook een checksum. Hetzelfde is van toepassing op de gebruikte databases. In beide gevallen zou ik dan na 3 jaar echt wel problemen verwachten als DDR5 zonder full ECC zo onbetrouwbaar is.
Laat staan de rommel die we dan elke dag produceren op onze desktop, laptop en telefoon: na een week is er geen bestand meer dat niet corrupt is en moeten we elke website wel 5x laden voordat deze zonder corrupte tekens op het scherm staat

Desalniettemin geeft ECC veel meer zekerheid natuurlijk. Het verlaagt het risico, tenzij de fout zo groot is dat zelfs ECC het niet meer kan corrigeren.

Zakelijk en voor kritische systemen blijft ECC een no-brainer. Maar voor privé zie ik er niet direct het nut in. Het zou anders zijn als ik elke week een foutmelding zou krijgen.

Noot:
Dit alles gebaseerd op eigen ervaring

[latka]

croque_monsieur schreef op donderdag 23 juli 2026 @ 10:51:
Bij ibecc wordt 1/32ste deel van het geheugen gereserveerd voor de ecc informatie. Terwijl bij unbuffered ECC een chip extra is. Dus ipv 64bit bus heb je 72bit, dat is 8 bits aan ECC informatie per 64 bit aan data.

Waar ik bang voor ben is dat bij IBECC minder fouten kunnen worden gefixed dan bij normaal ECC. Er zijn minder gegevens voor de error correction.

Voor detection is 1 bit genoeg (parity). Op het moment dat je ecc voor multibit error correction in moet gaan zetten is je hardware zo flaky dat ik het snel zou vervangen. Zeker ook omdat ddr5 al onboard ecc doet is een parity error al een hele harde waarschuwing dat je moet nadenken over vervangen (je lanes tussen memory en cpu zijn dan niet goed oid.) Maar het klopt dat ibecc geen 2-bit errors kan corrigeren en volledige ecc wel. Hoe relevant dat is? Voor Voyager die voorbij Pluto vliegt behoorlijk, voor een thuis server die je kunt repareren/vervangen wellicht minder.

[croque_monsieur]

latka schreef op donderdag 23 juli 2026 @ 11:49:
[...]

Voor detection is 1 bit genoeg (parity). Op het moment dat je ecc voor multibit error correction in moet gaan zetten is je hardware zo flaky dat ik het snel zou vervangen. Zeker ook omdat ddr5 al onboard ecc doet is een parity error al een hele harde waarschuwing dat je moet nadenken over vervangen (je lanes tussen memory en cpu zijn dan niet goed oid.) Maar het klopt dat ibecc geen 2-bit errors kan corrigeren en volledige ecc wel. Hoe relevant dat is? Voor Voyager die voorbij Pluto vliegt behoorlijk, voor een thuis server die je kunt repareren/vervangen wellicht minder.

Bedankt voor je uitleg. Het wordt me alleen nog niet helderder. Je zegt dat voor detectie 1 pariteitsbit voldoende is. Alleen per hoeveel bits is dat, per 8 bit? Dan zou je toch meer dan 1/32ste aan geheugen moeten reserveren? Daarnaast dacht ik dat normaal/sideband ECC geheugen ook geen 2 bit errors (SECDEC) kan repareren, wel detecteren.

Gelukkig hoeft mijn thuisserver niet voorbij pluto te werken.

[latka]

Mars Warrior schreef op donderdag 23 juli 2026 @ 09:32:
[...]

Hmm. Ik draai al 10 jaar zonder ECC en zonder scrub errors. Dus wat zegt dat dan 😇😬

Dat je harder moet scrubben ;-) Maar het klopt. Ik gebruik nu al 10+ jaar ZFS. Na 1 akkefietje met een kapotte dimm gevonden met ZFS scrub heb ik verder geen EDAC meldingen in de kernel meer gezien. Dus het blijft vooral een 'het kan misgaan'. En als de vakantiefotos niet meer leesbaar zijn dan heb ik heel wat uit te leggen hier thuis.

[latka]

croque_monsieur schreef op donderdag 23 juli 2026 @ 11:59:
[...]

Bedankt voor je uitleg. Het wordt me alleen nog niet helderder. Je zegt dat voor detectie 1 pariteitsbit voldoende is. Alleen per hoeveel bits is dat, per 8 bit? Dan zou je toch meer dan 1/32ste aan geheugen moeten reserveren? Daarnaast dacht ik dat normaal/sideband ECC geheugen ook geen 2 bit errors (SECDEC) kan repareren, wel detecteren.

Gelukkig hoeft mijn thuisserver niet voorbij pluto te werken.

1 bit parity voor een onbeperkte hoeveelheid bits....

Parity is, simpel gezegd, 1 als het aantal bits in je data even is en 0 als het oneven is. Dus binair:

010 -> parity 0
011 -> parity 1

Maar dat werkt natuurlijk ook met meer dan 3 bits, dus:

010101010101010101010101 -> parity 1

met 1 bit parity kun je dus 1 bit errors detecteren in desnoods 32Gb. Het duurt alleen te lang om voor iedere read/write het hele geheugen te lezen.
En met 1 bit parity kun je dus niets repareren (je weet niet welk bit er omgeklapt is, alleen dat er 1 omgeklapt is). Normaal ECC kan 1 bit errors repareren (en detecteren) en 2 bit errors alleen detecteren. Je OS moet het wel rapporteren (EDAC driver). IBECC kan dus alleen 1 bit errors detecteren (en tegenwoordig in Linux ook rapporteren).

[croque_monsieur]

latka schreef op donderdag 23 juli 2026 @ 12:09:
[...]

1 bit parity voor een onbeperkte hoeveelheid bits....

Parity is, simpel gezegd, 1 als het aantal bits in je data even is en 0 als het oneven is. Dus binair:

010 -> parity 0
011 -> parity 1

Maar dat werkt natuurlijk ook met meer dan 3 bits, dus:

010101010101010101010101 -> parity 1

met 1 bit parity kun je dus 1 bit errors detecteren in desnoods 32Gb. Het duurt alleen te lang om voor iedere read/write het hele geheugen te lezen.
En met 1 bit parity kun je dus niets repareren (je weet niet welk bit er omgeklapt is, alleen dat er 1 omgeklapt is). Normaal ECC kan 1 bit errors repareren (en detecteren) en 2 bit errors alleen detecteren. Je OS moet het wel rapporteren (EDAC driver). IBECC kan dus alleen 1 bit errors detecteren (en tegenwoordig in Linux ook rapporteren).

Ok nu snap ik het, dan zal IBECC ws 1 parity bit per 4 bytes gebruiken. En wordt het OS relatief vaker "lastig" gevallen dan bij normaal ECC ram, omdat hij het niet kan repareren.

[latka]

croque_monsieur schreef op donderdag 23 juli 2026 @ 12:27:
[...]

Ok nu snap ik het, dan zal IBECC ws 1 parity bit per 4 bytes gebruiken. En wordt het OS relatief vaker "lastig" gevallen dan bij normaal ECC ram, omdat hij het niet kan repareren.

"Lastig vallen" loopt ook voor 1 bit errors met ecc: je wil echt weten dat je hardware aan het sterven is en 1 bit errors zijn daar een voorbode van. Dus de edac driver meld netjes dat er een error gefixed is. Omdat ecc en raid geen vervanging zijn voor een backup is dat het moment om je hardware na te lopen, connectoren schoon te blazen en eventueel te vervangen. Omdat ecc+raid (of zfs) geen vervanger is van een backup is vooral de vroege signalering fijn.

[croque_monsieur]

latka schreef op donderdag 23 juli 2026 @ 12:31:
[...]

"Lastig vallen" loopt ook voor 1 bit errors met ecc: je wil echt weten dat je hardware aan het sterven is en 1 bit errors zijn daar een voorbode van. Dus de edac driver meld netjes dat er een error gefixed is. Omdat ecc en raid geen vervanging zijn voor een backup is dat het moment om je hardware na te lopen, connectoren schoon te blazen en eventueel te vervangen. Omdat ecc+raid (of zfs) geen vervanger is van een backup is vooral de vroege signalering fijn.

Ok, good point. Maar ik neem aan dat bij reparatie door side band ecc, de opdracht gewoon door kan gaan, terwijl bij IBECC het nogmaals moet worden gedaan. Dan heeft het bij IBECC meer gevolgen als het OS IBECC niet ondersteunt, terwijl bij ECC veelal de fouten gerepareerd worden zonder tussenkomst van het OS.

Samenvatten heeft IBECC:
+ detectie van 1 bit + repatratie
+ detectie 2 bit fouten
(SECDEC implementatie)
- geen reparatie van fouten
- geen aanwijzing welke dimm fout is (meestal 1 bank, dus geen probleem)

[ Voor 5% gewijzigd door croque_monsieur op 24-07-2026 06:59 ]

[latka]

croque_monsieur schreef op donderdag 23 juli 2026 @ 12:39:
[...]

Ok, good point. Maar ik neem aan dat bij reparatie door side band ecc, de opdracht gewoon door kan gaan, terwijl bij IBECC het nogmaals moet worden gedaan. Dan heeft het bij IBECC meer gevolgen als het OS IBECC niet ondersteunt, terwijl bij ECC veelal de fouten gerepareerd worden zonder tussenkomst van het OS.

Samenvatten heeft IBECC:
+ detectie van 1 bit
- geen detectie 2+ bit
- geen reparatie van fouten
- geen aanwijzing welke dimm fout is

Je samenvatting klopt op het laatste punt na: de meeste bordjes met IBECC hebben maar 1 dimm-slot. Het grootste probleem wat ik zie met IBECC is dat zelfs als de hardware het technisch kan het wel ontsloten moet zijn in de bios. Odroid h4 had het initieel niet, pas in een latere bios update kwam het beschikbaar. Asrock heb ik gevraagd of ze het voor hun N100 board op wilden nemen in de bios en het antwoord was: nee. IBECC blijft behoorlijk niche.

[croque_monsieur]

Ja, het is zeker niche, maar gelukkig meer dan alleen odroid; lattepanda mu en sigma hebben ook IBECC en minisforum arm workstation ms-r1.

Ik ben er net nog even ingedoken. In theorie zou je IBECC ook SECDEC kunnen krijgen door het datablok groter te maken naar 255 bits. De benodigde hoeveelheid parity bits stijgt dan ook naar 8. (zie Wikipedia: Hamming code)

ik lees in de github code van de ibecc edac driver wel errors gecorrigeerd kunnen worden: https://github.com/torvalds/linux/blob/master/drivers/edac/igen6_edac.c en https://docs.zephyrproject.org/latest/hardware/peripherals/edac/ibecc.html

24-7: Ik lees dat IBECC SECDEC implementeerd, dus het kan ook double bit errors detecteren.

[ Voor 16% gewijzigd door croque_monsieur op 24-07-2026 06:58 ]

[Pana]

Ik gebruik momenteel mijn oude desktop (R5 5800X, 32GB ram, RTX2070 super) als docker host icm 3 oude NAS'sen (Syno DS716+, DS916+ en QNAP TS453A) met een hoop 2TB disken die ik her en der vergaard heb. Daarnaast heb ik ook een spare HP elitedesk mini G3 liggen met 16GB ram en een i5 7500T, maar deze is volgens mij net niet genoeg om Immich ML op los te laten en zo te gebruiken als zuinige host.

Dus igenlijk wil ik dat allemaal wel wat consolideren naar een kleinere en zuinige footprint, maar veel verstand heb ik er eerlijk gezegd niet van en ik zie soms de bomen door het bos niet. Via Azerty vond ik deze barebone gigabyte brix minipc voor 290 (op de zaak), wat me wel ok lijkt. 32GB DDR5 erin en SSD'tje dat ik nog liggen heb en dan ben ik wel klaar voor 600 euro denk ik. En dan zou ik eventueel een Ubiquity Unas pro 4 aanschaffen met (voorlopig) 2 refurbished 16TB disken of een pro 8 en volproppen met de bestaande 2TB's, wat dan mooi in mijn bestaande Ubiquity ecosysteem kan inhaken en als media storage kan dienen voor de gigabyte host.

De desktop en de NAS'en worden dan verkocht.

Eventueel de HP elitedesk dan nog gebruiken als tailscale entry point?
Is dit allemaal wat zinnig?

Of toch beter de desktop parts hergebruiken op een mATX bordje en zo een zuinige kleine kubusserver proberen te bouwen?

[ Voor 7% gewijzigd door Pana op 23-07-2026 15:29 ]

[Jerie]

Mars Warrior schreef op donderdag 23 juli 2026 @ 11:40:

Laat staan de rommel die we dan elke dag produceren op onze desktop, laptop en telefoon: na een week is er geen bestand meer dat niet corrupt is en moeten we elke website wel 5x laden voordat deze zonder corrupte tekens op het scherm staat

Ik noem dat puur geluk hebben.

'Corrupte tekens' is niet hoe het werkt. Dit is wat er dan plaats gaat vinden: 10% van alle Firefox crashes komen door bitrot. Bron: Firefox engineer die deze detectie ontwikkelde https://mas.to/@gabrielesvelto/116171750653898304

Om dat te detecteren kun je inderdaad al je data verifiëren. Ik heb al vaak genoeg gehad dat ZFS een silent corruption heeft opgelost, en ik gebruik ZFS al bijna 20 jaar. Op een systeem met ECC daarentegen, moet ik de eerste keer nog meemaken.

Het adagium van sommigen hier is dat een beetje meer stroom verbruiken voor veiligheid/zekerheid direct maar 'onzuinig' is. Op die manier kun je ook verdedigen om nog steeds plaintekst telnet gebruiken i.p.v. SSH.

[ Voor 11% gewijzigd door Jerie op 23-07-2026 16:01 ]

[RobertMe]

Jerie schreef op donderdag 23 juli 2026 @ 15:59:
Het adagium van sommigen hier is dat een beetje meer stroom verbruiken voor veiligheid/zekerheid direct maar 'onzuinig' is. Op die manier kun je ook verdedigen om nog steeds plaintekst telnet gebruiken i.p.v. SSH.

Voor een thuisserver, die je alleen thuis gebruikt, een prima optie toch Als "ze" op je netwerk zitten heb je al een ander probleem. En bij remote is de aanbeveling AFAIK ook wel om."beheer" achter een VPN te zetten. SSH over VPN is dan ook semi dubbelop.

Nee. Ook ik draai gewoon SSH hoor. telnet gebruik ik alleen om eens wat in plain text te doen. telnet naar een HTTP (niet S) server, of SMTP / .... En ook dan zit je al vaak met SSL en dus openssl s_client etc.

En intern komt HTTP i.p.v. HTTPS natuurlijk ook vaak voor (/kwam? Gezien browsers steeds meer features alleen over https ondersteunen. Zoals klembord toegang, webserial, ...). Nu verwacht ik niet dat die keuze vaak uit zuinigheid wordt gemaakt, maar het kan wel, en http zonder ssl/tls was jaren prima geaccepteerd voor een homelab. (En 10, 15 plus jaar terug was https zelfs op internet "zeldzaam" / "alleen waar nodig", zelfs webshops die alleen het betalen over https deden en gewoon de catalogus browsen over http).

[mrmrmr]

Jerie schreef op donderdag 23 juli 2026 @ 15:59:
Het adagium van sommigen hier is dat een beetje meer stroom verbruiken voor veiligheid/zekerheid direct maar 'onzuinig' is. Op die manier kun je ook verdedigen om nog steeds plaintekst telnet gebruiken i.p.v. SSH.

Dat is heel slechte vergelijking. OpenSSH verbruikt bijna niets.

Ik ben het helemaal eens met @Mars Warrior dat het energieverbruik en investering ECC niet rechtvaardigen. Ooit leek het erop dat Intel ECC standaard wilde maken, maar kennelijk kwam er tegenstand van verkopers van (overmatig dure) professionele producten, waardoor dat niet is gelukt.

Zoals jij ook wel weet bestaat er zoiets als een risicoberekening. Dat gaat om de waarde van hetgeen je probeert te beschermen. Als er een bitje omvalt in een stream of in een plaatje, merk je daar weinig of niets van. Als in: er is praktisch geen schade. Risico is een vermenigvuldiging van schade keer kans. Als er vrijwel geen schade is, is er geen reden voor bezorgdheid. Zelfs niet als de kans hoog zou zijn.

Het wordt natuurlijk helemaal anders als er een bedrijfsboekhouding draait op de server waar het wel wat uitmaakt of het gaat om 1.152.921.504.606.846.976 of 0 (dat is 1 bitje verschil in een 64 bit waarde). Waar mensen werken die betaald moeten worden. Dus ja, redundantie is prima, maar echt niet nodig voor thuis. Dat gaat dan geheel voorbij aan de geringe schade.

Ik snap het gevoel wel dat je het precies zo wilt doen als op het werk, maar er is wel degelijk een rationele verklaring achter de keuzes die je (kan) maken in een thuissituatie.

[Jerie]

Intel wilde geen ECC. Hadden ze zo kunnen doen, maar ze willen hun Xeon spul graag differentiëren. Terwijl je eigenlijk beter dat 1/8 deel van RAM op kunt offeren.

[...] Als "ze" op je netwerk zitten heb je al een ander probleem. [...]

'Ze' komen eenvoudig via IoT binnen, maar dan zitten 'ze' nog niet op je thuisserver. Als je telnet i.p.v SSH gebruikt is die horde veel kleiner.

Nee. Ook ik draai gewoon SSH hoor.

Precies, want zoveel CPU time kost het niet, en het is een prima manier om te authen.

telnet gebruik ik alleen om eens wat in plain text te doen. telnet naar een HTTP (niet S) server, of SMTP / .... En ook dan zit je al vaak met SSL en dus openssl s_client etc.

Daar gebruikt men doorgaans netcat voor, niet telnet.

[...] Nu verwacht ik niet dat die keuze vaak uit zuinigheid wordt gemaakt, maar het kan wel, en http zonder ssl/tls was jaren prima geaccepteerd voor een homelab. (En 10, 15 plus jaar terug was https zelfs op internet "zeldzaam" / "alleen waar nodig", zelfs webshops die alleen het betalen over https deden en gewoon de catalogus browsen over http).

Dat waren gouden tijdens voor onze diensten. Toen kwam Snowden en werd de infosec gemeenschap wakker (na jaren signalen afschuiven als 'is een samenzweringstheorie'). HTTPS-gebruik is sindsdien gestegen. En ja, dat deden we vroeger niet omdat het qua belasting te duur was. Dat is ook waarom die IP camera's met hun MIPSjes zo gaar zijn. Die hebben de resources niet.

Ik blokkeer zelfs uitgaand verkeer naar port 80. Komt niets goeds uit. Helaas doet Android (althans, Qualcomm o.a.) ook verkeer naar port 80, en wel voor je VPN loopt. Tot zo ver de killswitch...

PS: Ik denk overigens dat we het de komende tijd wel vaker gaan zien, de data corruptie. Vanwege het overvolle stroomnet of de digitale dreiging is de kans op locale power surges hoger.

edit:
In ieder geval wil ik jullie allen een advies nog geven: zet zonder PLP/UPS de write cache uit.

[ Voor 7% gewijzigd door Jerie op 23-07-2026 16:33 ]

[Twee]

croque_monsieur schreef op donderdag 23 juli 2026 @ 07:34:
Ik heb nu een odroid h3 als thuis server. Ik wil toch voor een ECC build gaan, ik zit te twijfelen tussen systemen met IBECC, bijvoorbeeld odroid h4+/h5 of ik ga voor zelfbouw. Bij zelfbouw zat ik te denken aan een oude ryzen pro 4750G icm 550 mobo en DDR4 ecc geheugen.

De odroid hebben een idle van rond de 4-5 watt en een max van 25 watt, terwijl de ryzen setup een idle heeft van rond de 20-25w en een max. van 65-80 watt. Terwijl de ryzen(Geekbench Multi-Core 7463) maar een beetje sneller is dan de odroid h5 (Geekbench multi core 5178).

[...]

Ik weet niet precies waar je die scores vandaan hebt, maar ik denk dat het verschil in performance groter is dan dat. Als ik het opzoek bij Passmark zie ik dat een 4750G ruim twee keer zo snel is als een N300 (Odroid H5). Benchmarks hebben zo hun beperkingen, maar dat lijkt me een stuk realistischer.

---

Jerie schreef op donderdag 23 juli 2026 @ 15:59:
[...]
Het adagium van sommigen hier is dat een beetje meer stroom verbruiken voor veiligheid/zekerheid direct maar 'onzuinig' is. Op die manier kun je ook verdedigen om nog steeds plaintekst telnet gebruiken i.p.v. SSH.

Ik lees al een hele tijd mee in dit topic. Je stelt het wat scherp, maar m.i. heb je wel een punt. Dit topic kan soms wat eenkennig zijn, waarbij alleen de aller, aller zuinigste server acceptabel is. Usecases waar dat niet in past bestaan niet, of moet je dan maar aanpassen. Niet om de mensen die zo veel kennis bijdragen nou voor het hoofd te stoten, maar wat mij betreft mag het een tandje minder. Er zijn meer wegen naar Rome.

Simpel voorbeeld: de huidige generatie van het welbekende Kontron bord ondersteunt geen ECC, maar de vorige generaties wèl. Als je kunt leven met de performance van Intel 9th gen (eventueel een Xeon variant, ook die kunnen zuinig zijn) dan kun je daar een zuinige server met ECC mee bouwen. Veel mensen overschatten de CPU performance die een thuisserver nodig heeft behoorlijk, als je niet aan AI/ML doet dan voldoet zo'n oude CPU vaak prima. Toegegeven, het kan wel een uitdaging zijn om dat spul nog tweedehands te vinden.

Je kunt uiteraard ook geen ECC gebruiken. Ik zeg niet dat dat mòet, het is maar net wat je wil en/of wat je belangrijk vindt. Er zijn opties.

[ Voor 39% gewijzigd door Twee op 23-07-2026 18:08 ]

[RobertMe]

Jerie schreef op donderdag 23 juli 2026 @ 16:26:
[...]


'Ze' komen eenvoudig via IoT binnen, maar dan zitten 'ze' nog niet op je thuisserver. Als je telnet i.p.v SSH gebruikt is die horde veel kleiner.

offtopic:
IoT hoort natuurlijk op een gescheiden VLAN.
En SSH op mijn server(s) is ook alleen bereikbaar in het infra VLAN waar alleen mijn PC/laptop/... naartoe mogen (vanaf het "prive" VLAN) en niet de apparaten van andere gezinsleden.

[croque_monsieur]

Heeft er iemand ervaring met een recente intel ecc build met lage idle?

[croque_monsieur]

Pana schreef op donderdag 23 juli 2026 @ 15:26:
Ik gebruik momenteel mijn oude desktop (R5 5800X, 32GB ram, RTX2070 super) als docker host icm 3 oude NAS'sen (Syno DS716+, DS916+ en QNAP TS453A) met een hoop 2TB disken die ik her en der vergaard heb. Daarnaast heb ik ook een spare HP elitedesk mini G3 liggen met 16GB ram en een i5 7500T, maar deze is volgens mij net niet genoeg om Immich ML op los te laten en zo te gebruiken als zuinige host.

De i5 7500T lijkt me sneller dan mijn odroid h3, daar draai ik momenteel immich met ML op. Ik denk dat het zou kunnen. Het is de eerste sessie vooral langzaam dan moet hij alle foto's door. Daarna gaat het prima.

Mocht je alles willen samenvoegen tot een apparaat. Er zijn mensen die compute en storage gescheiden willen houden.

[GioStyle]

Oh, we hebben hier weer een ECC vs non-ECC discussie? Dan loop ik even een blokje om.

Ik heb mijn Odroid H4 Ultra verkocht, een H5 voor teruggekocht en mijn opstelling weer aangepast, maar de bedoeling is dat dit jaren blijft werken;

Primary server:
Case: Hardkernel Odroid H5 Type 1
Fan: Noctua NF-A9x14 PWM
SBC: Hardkernel Odroid H5
Memory: Samsung M425R2GA3BB0-CQKOL (1x16GB 4800Mhz)
SSD1: SK hynix PC711 256GB
SSD2: SK hynix PC711 256GB
SSD3: Lexar NM790 4TB
Power supply: Leicke 12V7.5A

De SK hynix ssd's in ZFS mirror, tig aantal containers in gebruik, 1Gbit aangesloten en het verbruik schommelt tussen de 4 en 5W.

Secondary (backup) server:
Case: Hardkernel Odroid H4 Type 1
Fan: Odroid DC Cooling Fan
SBC: Odroid H4
Memory: Crucial CT16G48C40S (1x16GB 4800Mhz)
SSD: Lexar NM790 4TB
Power supply: Leicke 12V5A

De tweede server wordt gebruikt voor backup AdGuard Home (DNS) in combinatie met Keepalived. Daarnaast is het ook een backuplocatie voor dagelijkse snapshots van de primary server. Verbruik ligt rond de 2,2/2,4W.

Heel misschien ga ik mijn 16GB van de H4 downgraden naar 8GB en van de H5 upgraden naar 32GB, maar voor de rest zijn dit wel de setups die ik de komende jaren niet meer wil gaan aanraken.

Mocht ik wat VM's willen opstarten om het een en ander te testen, dan ga ik mijn GMKtec K12 dualbooten met Windows/Proxmox, zodat die andere twee servers compleet met rust gelaten kunnen worden.

[Mars Warrior]

GioStyle schreef op donderdag 23 juli 2026 @ 20:13:
Oh, we hebben hier weer een ECC vs non-ECC discussie? Dan loop ik even een blokje om.

Het is geen discussie. Het zijn gewoon feiten

Ik heb mijn Odroid H4 Ultra verkocht, een H5 voor teruggekocht en mijn opstelling weer aangepast, maar de bedoeling is dat dit jaren blijft werken;

Primary server:
Case: Hardkernel Odroid H5 Type 1
Fan: Noctua NF-A9x14 PWM
SBC: Hardkernel Odroid H5
Memory: Samsung M425R2GA3BB0-CQKOL (1x16GB 4800Mhz)
SSD1: SK hynix PC711 256GB
SSD2: SK hynix PC711 256GB
SSD3: Lexar NM790 4TB
Power supply: Leicke 12V7.5A

De SK hynix ssd's in ZFS mirror, tig aantal containers in gebruik, 1Gbit aangesloten en het verbruik schommelt tussen de 4 en 5W.

Secondary (backup) server:
Case: Hardkernel Odroid H4 Type 1
Fan: Odroid DC Cooling Fan
SBC: Odroid H4
Memory: Crucial CT16G48C40S (1x16GB 4800Mhz)
SSD: Lexar NM790 4TB
Power supply: Leicke 12V5A

De tweede server wordt gebruikt voor backup AdGuard Home (DNS) in combinatie met Keepalived. Daarnaast is het ook een backuplocatie voor dagelijkse snapshots van de primary server. Verbruik ligt rond de 2,2/2,4W.

Jij boft dat je met zuinige bordjes uit kan komen met weinig RAM. Ik ben maar wat blij met mijn 24c/32t CPU en 128GB RAM.

Eerdaags krijg ik wel de beschikking over een 32c Xeon-server met 256GB ECC RAM en 2x 10Gbit netwerk. Daar ga ik het verbruik maar niet van meten. Gelukkig zijn de stroomkosten ook niet voor mij, maar voor de baas
Er zit geen storage in, dus die gaat over het netwerk naar een SSD-array

[GioStyle]

Mars Warrior schreef op donderdag 23 juli 2026 @ 21:11:

Jij boft dat je met zuinige bordjes uit kan komen met weinig RAM. Ik ben maar wat blij met mijn 24c/32t CPU en 128GB RAM.

In het verleden had ik 64GB zitten in een Odroid H3. Niet omdat ik het nodig had, maar omdat het kon. Met de huidige prijzen ben ik gewoon heel kritisch gaan kijken naar wat ik nodig heb. Een kale Debian met ZFS on Root heeft heel weinig nodig. Een beetje reserveren voor ARC en Docker en je bent er wel. Ik kan begrijpen als je complexe Dockerprojecten hebt draaien dat de vraag naar geheugen toeneemt, maar dat is hier niet het geval.

Hetzelfde geldt voor mijn nas. Daar had ik 2x16GB geheugen in zitten, maar mijn nas serveert alleen maar films/series via Samba. Die heb ik ook teruggeschaald naar 2x8GB geheugen.

[croque_monsieur]

Ik lees net dat IBECC, SECDEC implementeert. Het lijkt er op dat het kwa veiligheid nagenoeg hetzelfde is als sideband ECC. Ik neig er daarom naar (vanwege de huidige prijzen voor ECC geheugen) om dan voor odroid h4/h5 of lattepanda mu/sigma te gaan.

Zijn er nog redenen om toch side band ECC te gebruiken, behalve dat het sneller is en geen geheugen kost?

Heeft iemand ervaring met lattepanda, deze bordjes hebben sneller geintegreerd LPDDR5 geheugen dan odroid?

Daarnaast scheiden jullie het liefste de storage van de compute of hebben jullie het liefst een geintegreerde homelab/server?

[ Voor 14% gewijzigd door croque_monsieur op 24-07-2026 07:21 ]

[jvwou123]

croque_monsieur schreef op vrijdag 24 juli 2026 @ 07:07:

Daarnaast scheiden jullie het liefste de storage van de compute of hebben jullie het liefst een geintegreerde homelab/server?

voor thuis: ik heb het liefst zo weinig mogelijk, dus alles lekker in 1, scheelt ruimte, en stroom. Thuis heb ik maar ruimte voor 5u, en die is nu vol met: unifi switch, unifi cloud gen2+, patch paneel en rangeerrack, en een server die alles doet. Op het “rack” staat nog een ds918+ die ik probeer uit te faseren, dus die tel ik al niet meer mee.