Kompakter, Stromsparender HomeServer

Hallo,

ich war/bin auch auf der suche nach einem Stromsparenden & günstigen Home Server. Habe einige Zeit im Netz
verbracht um etwas passendes zu finden. Somit bin ich zu den folgenden Komponenten gekommen.
Gehäuse - MS-Tech LC-185, Mainboard - Intel Essential Series D945GSEJT laut Doc´s von Intel 12,3W
inc. 2GB Ram + alle Board Extention enabled (usb Tastatur & Mouse), HDD - Samsung EcoGreen F2 1TB ca. 5,8W
Netzteil habe ich schon ist ein 12V/75W. So das war es auch schon. Ich denke mal das dieses System für meine
Ansprüche völlig aussreicht, das wären Daten download, & FTP/VPN Zugriffe von Unterwegs. Da ich leider zufast
100% im Ausland tätig bin & ich einen Zugriff auf meine Daten Zuhause bisher als sehr hilfreich gezeigt hat sollte
dieses System 24/7 im Einsatz sein. Von daher lege ich eben großen Wert auf den geringen Strom Bedarf. Nur mit
dem OS da habe ich leider noch keinen richtigen Plan. Habe seit ca. 6 Wochen ein Netbook (Atom 230) mit mir mit,
das hat Win XP drauf und das zeigt nach 10 bis 12 Tagen das es doch besser ist es einmal neu zu Booten. Auf meinem Alten Server macht das nicht soviel aus da der doch genug reserve hat um das langsam werdende Win XP in Schwung
zu halten. Somit brauche ich ein Neues OS, nur welches? Am besten eines in das ich mich (bis dato nur Win) schnell
einarbeiten kann. Vielleicht hat ja der Eine oder Ander einen Tip für mich.
have a nice day
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
ein linux wäre optimal, ob die einarbeitung bei dir schnell geht hängt auch von deinem verständnis dafür ab,
kannst ja auch da ne grafikoberfläche nutzen,
generell is ein linux dahingehend die beste wahl
 
also wenn man damit nicht arbeitet und ständig was installiert usw, sondern nur die Dienste nutzt und Updates etc manuell durchführt, dann rennt auch ein XP ewig. (oder Server 2003/2008 und Co), falls nicht macht man was falsch.
 
meist ist eher der speicher das problem, für 24/7 ist ecc einfach besser
 
normaler speicher ist nicht für 24/7 ausgelegt, wenn der daten lange halten muss ohne das die refreshed werden solls da vorkommen können, dass sich fehler einschleichen, darum nutzt man in server oft ecc oder bufferd speicher

bin aber kein spezialist, denk da melden sich noch leute zu,
eigentlich stellt das halt wenig probleme dar, aber bei 24/7 kanns halt welche geben, neustart und gut, is halt nur nicht immer praktikabel

andererseits, n neustart alle sagen wir 10 tage, kann man auch automatisieren
 
Zuletzt bearbeitet:
normaler speicher ist nicht für 24/7 ausgelegt, wenn der daten lange halten muss ohne das die refreshed werden solls da vorkommen können, dass sich fehler einschleichen, darum nutzt man in server oft ecc oder bufferd speicher

bin aber kein spezialist, denk da melden sich noch leute zu,
eigentlich stellt das halt wenig probleme dar, aber bei 24/7 kanns halt welche geben, neustart und gut, is halt nur nicht immer praktikabel

andererseits, n neustart alle sagen wir 10 tage, kann man auch automatisieren

Öhm, das interessiert mich auch mal. Woher hast Du diese Informationen und wie kommst Du darauf, dass der nicht ECC-Speicher nicht refreshed wird?
 
refreshed schon abe rohen fehlerkorrektur, sorry,

die infos sidn schon älter,
quellen behält man ja irgendwann nicht mehr :(

die relevanz von fehlern nimmt halt mit speichergröße und der verweildauer der daten im ram zu

beim server wird oft viel ram eingesetzt und lange zei btrieben,
solche fehler können a zu sbstürzen führen, oder b. dazu das ein programm merkt das es müll rechnet und von vorn anfängt (wird langsamer)
naja, normal braucht man das ja nicht, nur wenn einem das system regelmäßig lahm wird, kann man ja schon mal überlegungen dahingehend anstellen
 
Speicherzellen neigen dazu, dass die Bits nach einiger Zeit(Milisekunden) kippen.
Hast man also viele statische Infos im RAM steigt die Wahrscheinlichkeit, dass die Infos im RAM unbrauchbar werden. Dieses Szenario tritt überlicher Weise in Serverumgebungen auf. Es gibt zwar einen regulären Refresh in den RAM-Zellen, dieser beruht aber auf keinem Prüfverfahren. Das heißt, man geht davon aus, dass der RAM refeshed wird. Sollte es aber mal dazu kommen, dass bei einer Zelle der Refresh schief läuft hat man ein Problem.

Um diesem Problem entgegenzuwirken wurde ECC entwickelt. Das erkennt solche Vorgänge und reagiert entsprechend.

Für gewöhnlich sind die Infos im RAM aber so schnelllebig, dass sie ständig neu geschrieben werden, somit kommt es zu keinen statischen Infos im RAM.

Es geht wirklich nur um die 100%ig statischen Inhalte UND dass der Refresh versagt, dann greift ECC.
 
also quasi ein stehendes programm im server, das auf etwas wartet?? sehe ich das richtig?
 
zB (er selten der Fall)
Aber zB ne DB die im RAM vorgehalten wird. (klassischer Fall)

Man darf aber nicht vergessen, dass man aktuell so viele Speicherzellen hat (auf Grund von zB 128GB RAM) dass die Wahrscheinlichkeit eines defekten Bits gefährlich hoch ist.
 
Zuletzt bearbeitet:
jupp, wir reden hier aber von normalen pc-komponenten im bereich von 8 gb ram ;) aber selbst da reicht es ja,
ist die db unbrauchbar im ram, muss sie von der hdd neu geladen werden, also wirds quälend langsam ;)

das man bei 128gb rm ecc braucht, is schon klar, bei 4-8 gb scheint das ansatzweise unwichtig, ist es aber im einzelfall nicht ;)
 
Man muß dem Fehler aber auch bemerken.

Wenn aus 1001000100101011010 -> 1000000100101011010 wird, dann muß man dass erstmal feststellen und da ist schon das erste Problem, vom reparieren red ich noch garnicht. Bekommt man das nicht mit, so rechnet man mit fehlerhaften Infos. Jetzt hängt es einzig von der Entropie ab, ob der Fehler Auswirkungen hat oder net.

Man kann es so sehen, es kippt garantiert ein Bit, die Frage ist nur wann. (also 10x am Tag oder 100x am Tag) Und jedes zuviel gekippte Bit ist ein schlechtes Bit.

Wie gesagt, bei kritschen Anwendungen auf jeden Fall ECC, beim Heimanwender ist es fast zu vernachlässigen. Ich betreibe hier schon seit etlichen Jahren 0815 Rechner 24/7 und bisher kein Problem. (in meinem Anwendungsfall hab ich keine bemerkt)
 
Der Refresh geschieht doch in so kurzer Zeit, da kann doch potentiell gar nix passieren...

Ebenso sollte es schnuppse sein, ob die Kiste 24/7 rennt oder eben nur paar Stunden am Tag. Der Refresh geschieht soweit mir bekannt kontinuierlich, sprich egal ob nun die Zelle den Inhalt nun schon über Stunden hat oder nicht, nach ner bestimmten Zeit wird Refresht undabhängig vom Inhalt.

Also dramatisch ist das bei weitem nicht, klar kann so ein Fehler immer passieren, und dafür gibts den ECC Ram oder andere Techniken, idR passiert da aber gar nix. Auch nicht mit xxx vielen GB Speicher...
 
Der refresh passiert alle 64ms glaube ich, es ist aber so, dass der refresh eben nicht bestätigt wird, dass heißt, wird eine Zelle mal "vergessen" bekommt man das nicht mit und dann kann das Bit sehr schnell kippen. Wenn man lange (die selben) Daten im RAM vorhält steigt die Wahrscheinlichkeit, dass die Daten, trotz geringer Entropie, unwiederbringlich defekt sind. Und genau da liegt das Problem.

@ECC
Genau darum gehts ja. Wie "sicher" sind die Daten im RAM ohne ECC.
(Dass ECC genau dafür gemacht wurden ist ja nicht der Streitpunkt.)
 
Aber was hat das ganze dann mit 24/7 Betrieb zu tun?

Wenn der Refresh alle 64ms angeleiert wird, dann vergehen x Millionen viele Refreshs selbst, wenn der PC nur eine Stunde laufen würde...
Wäre es so gefährlich non ECC Speicher einzusetzen, wäre der auch in Homeuserbereich schon lange verschwunden...

Der Inhalt der Speicherzelle spielt ebenso keine Rolle, ob da nun über lange Zeit die selben Daten drin sind oder nicht... Wenn das Bit kippt, dann ist asche, egal was da nun drin war und wie lange es vorher schon drin war. Dementsprechend steigt auch die Warscheinlichkeit nicht, wenn Daten lange an der selben Stelle im Speicher verweilen...
Dir kann das bei jeder Speicherzelle mit der selben warscheinlichkeit passieren (auch wenn das recht unwarscheinlich sein dürfte)
 
OMG ihr redet bei nem "Homeserver" von ECC? Habt ihr überhaupt ne Ahnung was das alled bewirkt? ^^
Ich würde ma sagen ECC ist in diesem Bereich sinnlos, weil ECC nur ein gekiptes Bit reparieren kann, nicht? Was passiert wenn mehr als 1 kakaputt ist? Er lädt von HDD nach... Resultat: ECC verhindert größtenteils das Nachladen, mehr aber auch nicht.

Bevor man mit ECC beginnt sollte man abwiegen wie schlimm es ist! Ich sage das jetzt bewusst: Ich bezweifel dass du Anwendungen hast, die deutlich davon profitieren =) Nen Fileserver mit ECC macht nur in Umgebungen mit richtig viel Zugriffen Sinn...

Und mal ehrlich: Wenn ein Refresh nicht stattfindet, gibts automatisch beim Lesen einen Fehler -> Nachladen von HDD =)

Summasummarum: Macht nur Sinn wenn eine Anwendungen sehr empflich bzw. sehr schnell sein muss (also wo HDD Zugriffe möglichst vermieden werden sollen).
 
Zuletzt bearbeitet:
Sonne, die Wahrscheinlichkeit steigt sehr wohl.
Beispielszenario:
Es gibt pro Stunde 1 schiefgegangen Refresh. Es werden 10verlorene Bits benötigt, damit die Daten als ganzes defekt sind und nicht wiederverwendet werden können.

2 verschiedene RAM Verwendungen:
1. In der Summe wird der RAM jede Stunde einmal komplett mit neuen Daten beschrieben. (Homeuser)
2. In der Summe wird der RAM alle 2 Tage komplett neu beschrieben. (Server mit vielen statischen Inhalten)

zu 1.
Es kommt pro Turnus zu einem defekten Bit, der Datenbestand ist nicht gefährdet <10defekte Bits
zu 2.
Es kommt pro Turnus zu 48 defekten Bits. Da 10Bits ausreichen um den Datenbestand zu gefährden sind die Daten "4,8x defekt"

Es ist ja nicht so, dass schon ein Bit ausreicht um die Daten als Müll zu deklarien -> Entropie (abhängig von den Daten)
Somit ist es schon wichtig was für Daten (Empfindlichkeit) wie lange im RAM lagern.

Es gibt keinen Lesefehler in dem Sinn. Die Daten werden in den RAM geschrieben und anschließend wieder ausgelesen. Es kommt bei diesem Vorgang zu keinem Vergleich der Daten, dass heißt man weiß nicht, ob die Daten korrekt sind oder nicht. Daher wird auch nicht von der HDD nachgeladen.
(Das ist auch der Grund warum beim RAM übertakten es zu bluescreens kommt. Der gelesen RAM-Inhalt ist so stark beschädigt(oder bei der Übertragung), dass sich das BS aufhängt. Wenn denn bei Lesefehlern von der HDD nachgeladen würde, würde es zu keinen BSs kommen.)
Um sowas zu umgehen müßte man Prüfsummenvergleiche anstellen und das wiederum macht den Sinn des RAMs zu nichte. Oder man nimmt ECC.

Es ist einfach so, dass man bei schnellen RAMumläufen die Gefährlichkeit von "Kippbits" sinkt. Hat man also ein solches Szenario, dann muß man nicht zwingend auf ECC setzen. Und gerade bei den Homeusern (und Desktops) ist das der Fall, daher muß man hier nicht auf ECC setzen. In Servern hingegen kann es schon Sinn machen, ob nun bei Homeserver sei dahingestellt.
Oft ist es ja auch so, dass bei den "besseren" Boards nichts anderes als ECC RAM verwendet werden kann. (da es kaum non ECC registered RAM gibt)
 
Zuletzt bearbeitet:
Hi,

noch was schnelles zum RAM. Meiner Meinung nach spielt es im Home Betrieb keine rolle ob man ECC oder non ECC verwendet. Ich kenne einige Klein & Mittelständige Unternehmen die haben keine ECC RAM mehr in ihren Servern da Sie auf "normale" Desktop/Tower Rechner als Server setzen wenn es die Anwendungen erlauben. Wenn die Rechen Knechte schnell genug getauscht werden ( run time 1Jahr max) ist das denke ich mal sowie so die Kostengünstigere Variante.
Für meine Anwendungen reicht ein non ECC Speicher alle mal, was ich nicht möchte das sich das OS selbst zumüllt und mit der Zeit sich immer mehr mit sich selbst beschäftigt statt seiner arbeit nach zu gehen. So gesehen ist Win XP sicher kein parade Beispiel. Ich habe die Befürchtung das mein SOHO Rechen Knecht mit der Zeit mehr mit sich zu tun hat als mit der von mir estellten Aufgaben. Möchte es vermeiden das ein Kollege alle Woche bei mir Zuhause vorbei schauen muss um den Rechner einen Hardware resett zu verpassen das dieser wieder spurt.
Denke ich werde es zuerst einmal mit einern WIn XP sp3 versuchen & dann mal schauen wie es wird. Kann das aber erst in 2-3 Wochen testen wenn ich wieder back in Good old Germany bin ;)
have a nice time
 
wieso planst du nicht alle 7 bis 10 tage nen restart, das müsste eigentlich gehen, und wenn du den zeitlich geschickt legst, kannst du das auch hinbekommen, das du das wohl nie merks ;)
 
Hi Shadow,

ich habe leider keine Ahnung wie ich das hinbekomme das sich mein Rechen Knecht alle 7 oder 10 Tage von selbst Abschaltet und dann zuverlässig wieder Einschaltet. Muss aber zugeben das ich auch noch nicht nach einem Tool dafür gesucht habe. Wenn du da einen Tool kennst oder einen Weg das mit Bord Mittel zu Meistern dann bitte ich um diese Infos.
Have a nice day
 
OMG ihr redet bei nem "Homeserver" von ECC? Habt ihr überhaupt ne Ahnung was das alled bewirkt? ^^
Ich würde ma sagen ECC ist in diesem Bereich sinnlos, weil ECC nur ein gekiptes Bit reparieren kann, nicht? Was passiert wenn mehr als 1 kakaputt ist? Er lädt von HDD nach... Resultat: ECC verhindert größtenteils das Nachladen, mehr aber auch nicht.

Bevor man mit ECC beginnt sollte man abwiegen wie schlimm es ist! Ich sage das jetzt bewusst: Ich bezweifel dass du Anwendungen hast, die deutlich davon profitieren =) Nen Fileserver mit ECC macht nur in Umgebungen mit richtig viel Zugriffen Sinn...

Und mal ehrlich: Wenn ein Refresh nicht stattfindet, gibts automatisch beim Lesen einen Fehler -> Nachladen von HDD =)

Summasummarum: Macht nur Sinn wenn eine Anwendungen sehr empflich bzw. sehr schnell sein muss (also wo HDD Zugriffe möglichst vermieden werden sollen).

Zum Markierten, das ist definitiv nicht Standard, da die Anwendung idR davon ausgeht, das der gelesene Speicherhinhalt richtig ist, man müsste in dem Fall der Anwendung vorher Prüfsummen mitgeben, welche den Inhalt auf Richtigkeit überprüfen, geschieht dies nicht, arbeitet die Anwendung mit dem falschen gelesenen Wert weiter...

Mal als Beispiel dazu, du schreibst ne Anwendung, hast ein Array als Typ Byte (z.B. VB6 0-255) deklariert und füllst dieses Array nun mit Daten.
Nun willst du Array(7) zum Beispiel wieder auslesen, Array(7) wurde vorher mit 0000 0000 beschrieben, sprich Dez. 0, nun kippt ein Bit in der Binärfolge zum Beispiel auf 0000 0001, sprich Dez. 1...
Die Anwendung weis nicht, das dort hätte eigentlich 0 drin stehen müssen und ließt aber aus dem Speicher ne 1...

Du kannst dir selbst ausmahlen, was das für schwerwiegende folgen haben könnte.
Das könnte man abfangen über ein Bilden der Prüfsumme, diese müsste aber wiederum irgendwo stehen, wodurch ebenfalls die Gefahr besteht, das die Prüfsumme im Speicher falsch ausgelesen wird, bei nem kippenden Bit...
Nur wenn die Prüfsumme mit dem Inhalt nicht stimmt, weis die Anwendung, Array neu befüllen...

Je nach Komplexität des Programms stellt das aber ein Problem dar, da gerade Variablen oder Arrays doch dafür da sind, Daten zwischenzuspeichern und an anderer Stelle wieder neu einzubinden... Sprich man müsste in dem Fall mit guter Logik das Programm so gestalten, das derartige Arraybefüllungsvorgänge schnell und einfach wiederholbar wären... --> sehr sehr schwierig.

Sonne, die Wahrscheinlichkeit steigt sehr wohl.
Beispielszenario:
Es gibt pro Stunde 1 schiefgegangen Refresh. Es werden 10verlorene Bits benötigt, damit die Daten als ganzes defekt sind und nicht wiederverwendet werden können.

2 verschiedene RAM Verwendungen:
1. In der Summe wird der RAM jede Stunde einmal komplett mit neuen Daten beschrieben. (Homeuser)
2. In der Summe wird der RAM alle 2 Tage komplett neu beschrieben. (Server mit vielen statischen Inhalten)

zu 1.
Es kommt pro Turnus zu einem defekten Bit, der Datenbestand ist nicht gefährdet <10defekte Bits
zu 2.
Es kommt pro Turnus zu 48 defekten Bits. Da 10Bits ausreichen um den Datenbestand zu gefährden sind die Daten "4,8x defekt"

Es ist ja nicht so, dass schon ein Bit ausreicht um die Daten als Müll zu deklarien -> Entropie (abhängig von den Daten)

Somit ist es schon wichtig was für Daten (Empfindlichkeit) wie lange im RAM lagern.

Es gibt keinen Lesefehler in dem Sinn. Die Daten werden in den RAM geschrieben und anschließend wieder ausgelesen. Es kommt bei diesem Vorgang zu keinem Vergleich der Daten, dass heißt man weiß nicht, ob die Daten korrekt sind oder nicht. Daher wird auch nicht von der HDD nachgeladen.
(Das ist auch der Grund warum beim RAM übertakten es zu bluescreens kommt. Der gelesen RAM-Inhalt ist so stark beschädigt(oder bei der Übertragung), dass sich das BS aufhängt. Wenn denn bei Lesefehlern von der HDD nachgeladen würde, würde es zu keinen BSs kommen.)
Um sowas zu umgehen müßte man Prüfsummenvergleiche anstellen und das wiederum macht den Sinn des RAMs zu nichte. Oder man nimmt ECC.

Es ist einfach so, dass man bei schnellen RAMumläufen die Gefährlichkeit von "Kippbits" sinkt. Hat man also ein solches Szenario, dann muß man nicht zwingend auf ECC setzen. Und gerade bei den Homeusern (und Desktops) ist das der Fall, daher muß man hier nicht auf ECC setzen. In Servern hingegen kann es schon Sinn machen, ob nun bei Homeserver sei dahingestellt.
Oft ist es ja auch so, dass bei den "besseren" Boards nichts anderes als ECC RAM verwendet werden kann. (da es kaum non ECC registered RAM gibt)

Neja die Frage ist doch, wie viele Bit können kippen ohne das die Daten gänzlich unbrauchbar werden?
Im Worst Case Szenario reicht ein Bit um den Inhalt unbrauchbar zu machen, sprich davon sollte man auch ausgehen...

Und wie du schon richtigerweise sagtest, der Inhalt wird nicht auf Richtigkeit überprüft, was wiederum bedeutet, ist ein Bit falsch, ist der Inhalt falsch, das hat dann je nach Anwendung schwerwiegende Folgen. Es gibt sicher Anwendungen die dann von Haus aus nochmals auf den Inhalt prüfen und somit bei Fehlern neu lesen lassen... Aber ich stelle mir das gerade in Bereichen vor, so Systemkritische Vorgänge Statt finden, heist soviel wie, irgendwas mit dem OS, ist der Inhalt falsch, gibts unter Umständen nen komplett Absturz.


Ich bin aber der Meinung, das sich dieses Szenario nicht all zu oft ereignen dürfte, eben aus dem Grund, weils idR auch mit non ECC Speicher läuft... Wäre der Fehler derart hoch, das wie im Beispiel pro Stunde mindestens ein Bit kippt, wäre auch im Desktopbereich lange ECC Speicher Standard...
 
Ja, Du bist Schuld! ;)

Ich würde auch auf ECC verzichten bei Einsockelsystemen. Auch würde ich auf diese Slimline-Laufwerke verzichten. Sie sind teuer, schwach und von der Bauart her eher anfällig.
 
Vielleicht wäre es sinnvoller auf einen Amd statt auf einen Nvidia Chipsatz zu setzen.. Damit läsen sich sicherlich ein paar "Wättchen" einsparen. Und daran denken Cool n Quiet nutzen :) Spart auch einiges.. dazu noch undervolting und die Kiste ist perfekt... Ein Sempron LE wird für deine Zwecke sicherlich auch reichen. Der braucht trotz selber TDP sicher weniger als ein x2 :)

OT: Habe auch einen Fileserver am rennen... Werde einige Tipps aus diesem Thread umsetzen, z.B. WOL...
 
Vielleicht wäre es sinnvoller auf einen Amd statt auf einen Nvidia Chipsatz zu setzen.. Damit läsen sich sicherlich ein paar "Wättchen" einsparen. Und daran denken Cool n Quiet nutzen :) Spart auch einiges.. dazu noch undervolting und die Kiste ist perfekt... Ein Sempron LE wird für deine Zwecke sicherlich auch reichen. Der braucht trotz selber TDP sicher weniger als ein x2 :)

OT: Habe auch einen Fileserver am rennen... Werde einige Tipps aus diesem Thread umsetzen, z.B. WOL...

Die aktuell sparsamsten Chipsätze kommen aber von NV derzeit ;)
 
ich hab mir nen klein fileserver zusammengebastelt mit

-Amd x2 4400+ soll noch gegen 5050e oder 4850e getauscht werden
-boxed cpu lüfter
-Asrock alive nf7g -hdready (7050/630a)
-2gb ddr2-800 ram
-Seasonic S12// -380W
-Promise ex8350 controller
-Os platte 2.5 zoll wd3200bevt
-Raid_5 @4*1TB wd10eads (Wd-green idle 2.8W je platte laut hersteller)

verbraucht im leerlauf ca 58W

ist das ok oder zu viel für das system ?
 
Zuletzt bearbeitet:
cpu ist ja nicht optimal und raidcontroller plus hdds ziehen auch, finde das schon mehr als ok, erwarte mit dem 4850 oder 5050 keine zu große ersparnis mehr
 
der 4400+ ist auch nur ne übergangslösung bis ich ein der beiden anderen hab,
ich würde mal schätzen 2-3 watt weniger mit ein 4850.
bei ein noch kleineren be oder lv weis ich nicht wie die Systemleistung drunter leidet
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh