MalariaControl und die Festplatte

[respawner]

wieso entsteht bei Torrent ein permanenter Schreibzugriff? Wenn ich jetzt ein TB runterladen würde wären es zwar viele kleine Schreibzugriffe, aber die wären verteilt, eine SSD würde sich doch langweilen, eine HDD hat auch einen Cache, so dass sie nicht jede 512 oder 4096 Bytes einzeln abarbeiten müsste. Eine SSD kann man ja pro Zelle 1000 - 3000 mal beschreiben, also selbst wenn ich Torrent bis zum erbrechen benutze müsste ich ja mehrere hundert TB laden, also ständig das alte Zeugs wieder löschen.
Aber wenn ich Daten zur Verfügung stelle habe ich ja nur Lesezugriffe, dagegen ist eine SSD ja unempfindlich und da ich recht viele iops habe, wird die Internetverbindung das Nadelöhr sein. Bei einer normalen Festplatte wird das eher nervig, wenn ständig Leute alle möglichen Kleinteile von unterschiedlichen Bereichen der Platte abfragen. Aber Torrent bei Distributed Computing wäre vor allem sinnvoll wenn man mehrere Daten öfters braucht, also wie etwas die Binary der Dateien der Projekte, aber eben nicht die einzelnen Pakete, außer halt wenn ich meinem Wingman beliefere.
Interessant wäre es wohl eher wenn man Pakete hätte die auf andere Benutzer basieren, aber nicht auf Echtzeit angewiesen sind, aber selbst dann würde man nicht mit gigantischen Datenmengen umgehen.
Aber ich fände es auch schön, wenn man den Distributedansatz ein wenig von diesem sternförmigen Master-Client-Ansatz entfernt und auch etwas die Richtung Client-Client verwenden würde. Also wirklich WUs die auf andere aufsetzen direkt von User zu User übertragen, wenn man den Server dadurch gut entlasten kann, aber das würde natürlich extrem auf die Aufgabenart ankommen, da ja Internetverbindungen ja immer noch extrem langsam sind.
Richtige Simulationen wären damit ja nicht möglich, da da ein paar Mbit pro Sekunde viel zu langsam wären.
Cool wäre es bei WUs die lange brauchen aber möglichst schnell berechnet werden sollten, wenn ein PC wenn er heruntergefahren werden soll, die Arbeit schnell an einem anderen User weitergeben könnte, so dass keine wertvolle Zeit verloren gehen würde, weil der Nutzer vielleicht den PC erst wieder in 12 Stunden anmacht. Aber das wäre auch nur bei WUs möglich die man gut checkpointen könnte und wenig Speicher belegen würden, wenn man den Benutzer nicht zumuten wollte erst mal noch eine Stunde warten zu lassen bis er den Rechner ausmachen kann. Aber solche User würden den Rechner wohl sowieso 24/7 laufen lassen.

Zum virtuellen Speicher, das RAM selbst wird ja auch vom System zum cachen von Daten verwendet, dieser Speicher wird zwar als frei deklariert, wird aber trotzdem potentiell genutzt. Windows legt normalerweise ja nur das Zeugs vom RAM in den virtuellen Speicher, wenn es denkt, dass dieser Bereich sowieso selten benutzt wird, wenn er dann dafür ein paar mehr GB RAM für irgendwelche Caching-Dinge verwenden kann, die es vielleicht häufiger braucht wäre das RAM so sinnvoller ausgenutzt als hätte es Speicher nicht ausgelagert. Leider klappt das nicht immer, da ja Windows ja vorhersagen muss welchen Speicherbereich er in Zukunft wohl selten verwenden muss. Aber statistisch gesehen ist dieses Verhalten sinnvoller als erst zu warten wenn der Speicher voll ist.
Ich habe z.B. 32 GB RAM, es werden 8,8 GB RAM verwendet, aber es sind nur 88MB frei, 23,5 GB werden für Cache verwendet (im Taskmanager auf Resourcenmonitor gucken, da wird dies angezeigt).
Wie Linux und Macs das machen weiß ich nicht, aber ich denke viel anders wird es das auch nicht machen.

[yoyo]

Genau so ist das mit der Speicherverwaltung auch unter Linux. Ich halte daher das Abschalten des swap files für kontraproduktiv, ja sogar gefärlich. Im Wesentlichen weiß das Betriebssystem besser was im RAM und was im Swap zu halten ist und kann es vorallem dynamisch mal schnell ändern. Das Betriebssystem benutzt den RAM als Cache für Festplattenzugriffe.
Hier mal als Beispiel der yoyo@home Server, wo von 1GB RAM nichtmal 20% für Applikationen belegt sind, aber trotzdem kaum RAM frei ist und auch etwas ausgelagert ist:
https://www.dropbox.com/s/i6aosk94qcu3n ... y.png?dl=0

yoyo

[Dj Ninja]

Bei 32 GB RAM kann man es sich glaub ich erlauben, das Swapfile zu deaktivieren oder zumindest in der Größe stark einzuschränken.

Daß das OS freies RAM als Festplattencache verwendet, ist sehr sinnvoll, da sich dort am ehesten Daten sammeln, die bald und oft wieder gebraucht werden. Lesezugriffe werden dadurch erheblich beschleunigt und sollte eine Anwendung wirklich einmal sehr viel RAM belegen, können große Teile des Caches auch schnell verworfen und der Speicher der Anwendung zur Verfügung gestellt werden.

Hat der yoyo@home Server wirklich nur 1 GB RAM?

[yoyo]

Wir haben in der Firma Systeme mit 192GB RAM laufen und auch dort den swap NICHT ausgeschaltet!

Ja, der yoyo Server hat nur 1GB RAM.

[Kolossus]

Bei mir ist das Swapfile auch wieder am laufen, es ist tatsächlich die Veränderung in Boinc auf einen Eintrag von >=900sec bei den Schreibzugriffen und Ruhe ist auf der Festplatte. Man kann wieder die Stecknadel fallen hören und der Compi ist für alles zu haben, egal welche Projekte gerechnet werden, oder welche Programme/Spiele gerade parallel dazu laufen.....
Welch ein Glück, das ChristianB die Lösung gefunden hat!!!

[ChristianB]

Sehr schön das es funktioniert hat. Hier wäre es eigentlich für das Projekt wichtig eine Mindestcheckpointzeit anzugeben welche die Zeit des Benutzers überstimmt. Sowas macht RNA World aktuell bei den VM Aufgaben. Da habe ich die Mindestzeit zwischen zwei Checkpoints auf 30 Minuten gesetzt weil bei Rechnern mit >4 Aufgaben alle Aufgaben fast gleichzeitig auf die Platte schreiben wollten. Sowas gibt es aber für nicht-VM Aufgaben nicht.

[Dj Ninja]

Naja soweit ich das damals beim Entwurf meines 3x+1 Projekts ergründet habe, gilt diese Schreib-Zeitangabe für die Science App bestenfalls als Richtlinie. Praktisch KANN sie von der Platte lesen oder draufschreiben wann sie will und soviel sie will, sie muss sich nicht an die Vorgabe halten.

Mein Projekt hat sich darum schlichtweg gar nicht gekümmert, weder der Server noch die Science App konnte das. Allerdings bestand meine Checkpoint-Datei auch aus weniger als 1kByte Daten und ich hab sie immer nach einer bestimmten Anzahl Berechnungen schreiben lassen, was bei schnelleren Rechnern auch zu häufigerem Checkpointing führt. Angesichts der geringen Datenmenge ist das völlig egal und der User am Rechner merkt nicht das Geringste davon.

192 GB RAM sind cool. Ich hab hier eine Kiste mit 48 GB. Leider gibts keine Projekte, die das auch nutzen...

[Michael H.W. Weber]

192 GB RAM sind cool. Ich hab hier eine Kiste mit 48 GB. Leider gibts keine Projekte, die das auch nutzen...

Wenn Du genügend Kerne hast, würde ich Dir ATLAS@home anraten mit 4 GB RAM pro WU. Da hättest Du dann sogar gute Chancen, ziemlich weit oben mitzuspielen. Ich bin erst seit Anfang 2015 dabei und inzwischen mit 3 Maschinen auf Platz 57 - weltweit. Habe vor kurzem sogar auf meinem i5-Quad extra dafür das RAM auf 16 GB verdoppelt; "leider" rödeln da derzeit zwei RNA World Langläufer vor sich hin und bremsen mich etwas...

Michael.

[Dj Ninja]

Die Kiste hat 8 Cores... Naja mal sehen, ich kann das ja mal antesten wenn ich wieder korrektes DSL habe.

[Michael H.W. Weber]

Die Kiste hat 8 Cores... Naja mal sehen, ich kann das ja mal antesten wenn ich wieder korrektes DSL habe.

Ja, Du brauchst einen anständigen Internetzugriff, sonst kannste das Projekt gleich abhaken. Genau wie beim Schwesterprojekt vLHC@home muss das Netz permanent verfügbar sein, sonst pausiert Dir die WU.

Michael.

[Albert Brettermeier]

MC hat nach deren News und gerechneten WUs Anfang 2016 den DC-Betrieb eingestellt.