Upload per Remote (Skript) starten?

Hallo Freunde,

ich habe da ein Problem. Ich muss von einem anderen Rechner aus den Up/Download der BOINC-WUs steuern. Im Prinzip ganz einfach, wenn man als Mensch vor dem PC sitzt.

Ich hole mir mit "boinccmd --host <ip> --get_file_transfers" die Liste der Up/Download-Dateien. Mittels "boinccmd --host <ip> --file_transfer <projekt-url> <wu-name> retry" kann ich dann den Up/Download starten.

Und da liegt das Problem für ein Skript. Ich muss zu jeder Datei die richtige Projekt-URL und den WU-Namen angeben. Wildcards sind z.B. für den WU-Namen nicht möglich. Ich kann die Ausgabe von "--get_file_transfers" so parsen, dass ich nur die WU-Namen habe um diese an den "--file_transfer" Befehl weiterzuleiten. Da sich die Namen der WUs aber ständig ändern, ist eine Zuordnung der Namen zu einem Projekt quasi unmöglich.
Wenn ich jetzt 6 Projekte und 50 Up/Download-Dateien habe, müsste ich 6x50 Uploadbefehle übers Netz jagen. Ohne Zeitverzögerung gehen davon aber welche verloren, zumindest habe ich das so beobachtet. Nur einmal den Upload zu starten würde so 5 Minuten dauern.

Weiß jemand wie man den Upload einfacher starten kann? Also alle WUs auf einmal? Lieber wäre mir noch alle WUs eines Projektes auf einmal. Und wenn das nicht geht, wie ich z.B. per Perl-Skript die WUs einem Projekt zuordnen kann?

Im Moment haue ich einfach alle WU-Namen an ein Projekt, aber das gefällt mir wie gesagt nicht. Per Skript sieht das so aus (für GPUGRID):

#!/usr/bin/env perl

open($INP,"/usr/bin/boinccmd --host xxx.xxx.xxx.xxx --get_file_transfers|") || die "Konnte BOINC nicht starten - $!\n";
while(<$INP>)
{
   if(($n)=/\s*name:\s+(\S+)/)
   {
      system("/usr/bin/boinccmd --host xxx.xxx.xxx.xxx --file_transfer http://www.gpugrid.net/ $n retry");
      sleep(1);
   }
}
close($INP);

Das Skript ist nicht von mir, hat mir ein Freund geschrieben.

Falls jemand genaue Hintergründe für die Aktion wissen möchte, kann ich die gerne noch schreiben.

Echt blöd das BOINC (Boinc_cmd) keinen Befehl hat wie "boinccmd --host <ip> --file_transfer <projekt-url> retryall" um alle WUs anzustarten.

Ich würde mich sehr freuen wenn jemand eine Idee hat, Grubix.

Was soll das Skript denn ganz genau tuen ?
So wie ich das verstanden habe, soll es alle WUs eines Projektes auf Knopfdruck (bzw. als Cronjob) hochladen ?
Ist das nur für einen einzelnen PC gedacht auf den du per SSH/Boinc Manager Zugriff hast ?
Oder soll daraus so eine Art Programm werden ?

Fragen über Fragen

Wäre <report_results_immediately>1</report_results_immediately> in Form einer cc_config.xml nicht die einfachste Variante, so dass alle bearbeiteten Workunits automatisch an das entsprechende Projekt gemeldet werden?

Da müßte sich doch mittels BoincView realisieren lassen.

OK, dann muss ich doch etwas weiter ausholen.

Zitat von WBT112

Was soll das Skript denn ganz genau tuen ?
So wie ich das verstanden habe, soll es alle WUs eines Projektes auf Knopfdruck (bzw. als Cronjob) hochladen ?

Ja, genau, es läuft per Cronjob auf einem PC (Linux). Wenn das Skript gestartet wird, soll es alle Dateien (egal ob Up- oder Download) die unter "Übertragungen" stehen anstarten. Für alle Projekte.

Hintergrund: Die Rechner hängen an einer Internetleitung, die nicht immer funktioniert. Wenn jetzt z.B. ein Upload nicht geklappt hat, verzögert sich der nächste automatische Versuch um z.B. 30 Minuten. Nach ein paar erfolglosen Versuchen steht die Verzögerung dann gerne mal auf 24 Stunden. Habe ich öfters gesehen! Es könnte also jetzt sein, dass die Internetverbindung 20 Stunden lang funktioniert, BOINC aber keinen Versuch unternimmt, seine Dateien zu übertragen. Und wie es der Zufall so will, wenn er es dann wieder versucht, ist die Verbindung für 10 Minuten weg. Dann heißt es wieder 24 Stunden warten. Im Ergebnis laufen die Rechner leer, obwohl die meiste Zeit eine Verbindung möglich gewesen wäre.

Lösung: Egal welche Verzögerung sich BOINC für den nächsten automatischen Versuch ausgedacht hat, alle z.B. 15 Minuten wird die Übertragung gestartet. Quasi so also würde ich einen Affen vor den Rechner setzten der alle 15 Minuten auf "Jetzt nochmal versuchen" klickt.

Zitat von WBT112

Ist das nur für einen einzelnen PC gedacht auf den du per SSH/Boinc Manager Zugriff hast ?

Das ist im Moment für 4 PCs gedacht die am selben Switch wie der Linux-Rechner hängen. Ich kann mit boinccmd also ohne Probleme über die IP zugreifen.

Zitat von WBT112

Oder soll daraus so eine Art Programm werden?

Nein, der Linux-Rechner soll einfach nur per Skript, welches per Cronjob gestartet wird, die Übertragung starten. Mehr nicht. Das Skript das ich Oben geschrieben läuft bereits so und funktioniert für GPUGRID wunderbar. Ich habe es zunächst nur für GPUGRID gemacht, weil man hier schnell auf einige tausend Credits verzichtet, wenn fertige WUs einen Tag lang auf dem Rechner rumgammeln.

Es ist zwar z.B. für Einstein egal, wenn fertige WUs wegen der Probleme erst nach einer Woche hochgeladen werden, aber das muss ja nicht sein. Unabhängig davon gibt es natürlich auch immer das Problem, dass die Rechner leer laufen können. Selbst bei 10 Tagen Bunker kommt das vor, weil man meisten gar nicht so viele WUs bekommt. Ohne Internet hält ein voller Rechner so gut 5 Tage durch, bis er keine Arbeit mehr hat. Das ist meine Beobachtung mit den Projekten die ich rechne.

Daher wollte ich es jetzt für alle Rechner und alle Projekte machen. Aber es gefällt mir nicht für 4 Rechner jeweils z.B. 300 Uploadkommandos zu senden, wo tatsächlich nur 30 Stück notwendig wären. Der Traffic im Netz ist mir egal, ist ja alles intern. Die Zeit stört mich. Wenn der letzte Befehl raus ist kann ich ja mit dem ersten schon wieder anfangen. Und das bei einer "normalen" Übertragungsliste.
Neulich standen in der Warteschlange über 200 Einstein-Dateien zum Download, 150 Enigma-Files zum Upload und ein paar Yoyo, QMC und GPUGRID. Jetzt darf mal jeder Rechner: Rund 400 Dateien die mangels Zuordnung an 6 Projekte wiederholt werden müssen mit jeweils 1 Sekunde Verzögerung.

Zitat von lemarc

Wäre <report_results_immediately>1</report_results_immediately> in Form einer cc_config.xml nicht die einfachste Variante, so dass alle bearbeiteten Workunits automatisch an das entsprechende Projekt gemeldet werden?

Ne, das habe ich drin, hat aber nichts mit dem eigentlichen Problem zu tun. Das mit dem Melden der WUs war im Gegensatz zu den Up-/Downloadfiles ganz einfach. Hier gab es ja das gleiche Problem: BOINC wollte die WUs melden, hatte keine Verbindung und wollte es dann automatisch nach 30 Minuten nochmal versuchen. Nach ein paar erfolglosen Versuchen stand dann da gerne auch mal "Kommunikation verzögert um 23:48:17".
Mit boinccmd kann man das einfach erneut anstarten:

/usr/bin/boinccmd --host xxx.xxx.xxx.xxx --project http://www.gpugrid.net/ update
/usr/bin/boinccmd --host xxx.xxx.xxx.xxx --project http://www.enigmaathome.net/ update
/usr/bin/boinccmd --host xxx.xxx.xxx.xxx --project http://einstein.phys.uwm.edu/ update
usw. usf.

Für jedes Projekt ein Kommando, das geht Ruckzuck...

Zitat von Dude

Da müßte sich doch mittels BoincView realisieren lassen.

Ich kenne BoincView, aber einen automatischen "Dienst" der für alle Rechner das gewünschte macht, ist mir jetzt nicht in Erinnerung. Zumal es eigentlich über den Linux Rechner laufen muss, weil der als einziger immer läuft und nur ich Zugriff drauf habe. Die BOINC-Rechner können durchaus mal ausgeschaltet werden.

So, sehr viel geschrieben, ich hoffe ich konnte es einigermaßen erklären...

Eine kleine Idee, kann es leider gerade nicht nachprüfen: Werden die verzögerten Uploads nicht auch wieder angestoßen, wenn man im BOINC Manager auf "Kommunikation wiederholen" klickt? Das könnte man dann sehr einfach auch via boinccmd erreichen, --network_available (ein nützlicher Befehl, der in der offiziellen Dokumentation leider verschwiegen wird).

Zitat von pschoefer[SPEG]

... Das könnte man dann sehr einfach auch via boinccmd erreichen, --network_available (ein nützlicher Befehl, der in der offiziellen Dokumentation leider verschwiegen wird).

Die Option habe ich in der Tat in keiner Doku gesehen. In ca. zwei Stunden habe ich hier WUs fertig, dann probiere ich das aus. Wäre genial wenn daraufhin alle pausierten Up-/Downloads angestartet würden. Bitte Daumen drücken.

Der Parameter --set_network_mode veranlasst leider keinen Start von pausierten Up-/Downloads, wenn man damit den Netzwerkzugriff sperrt und wieder frei gibt.

Hat der Parameter --network_available noch eine Option, oder ist dir da nichts bekannt?

Danke für den Tipp, Grubix.

Reicht da nicht ein

boinccmd --project xyz update

über alle Projekte?
yoyo

Zitat von pschoefer[SPEG]

Eine kleine Idee...

Es funktioniert!
Alle Up-/Downloads die wegen Kommunikationsproblemen verzögert wurden, starten augenblicklich wieder an. Für alle Projekte. Sogar das Melden der WUs wird wieder angestoßen.

Danke für den Tipp, damit ist das Probleme beseitigt.

Zitat von yoyo[RKN]

Reicht da nicht ein

über alle Projekte?
yoyo

Um die WUs zu melden und neue zu holen, jein. Auf die Verzögerung des Up-/Downloads hat der Befehl keinen Einfluss. Ein konkretes Beispiel:

Ich konnte die fertigen OGR-WUs nicht hochladen, weil die Verbindung bei mir mal wieder weg war. Der nächste automatisch Versuch ist z.B. in 15 Stunden. Nun soll sich BOINC mit boinccmd --project <url> update neue Arbeit holen. Ich hatte 50 WUs, von denen jetzt 30 fertig sind, aber auf den Upload warten (s.o.). Fragt der Client nun nach neuer Arbeit, kommt vom Projektserver die Meldung "Hey, du hast schon 50 WUs, mach' die erstmal fertig bevor es was neues gibt". Die Meldung lautet zwar etwas anders, sagt aber genau das aus.

Ich muss die fertigen WUs erst hochladen und melden, damit es neue Arbeit gibt. Und da lag mein Problem, ich brauchte Projekt-URL und Upload-Namen, um den Upload wieder anzustarten.

Bis denn dann, Grubix.

Dann hat sich mein 4-Seiten langes Shell-Skript ja erledigt

Ne quatsch, hätte auch sowas wie lemarc (mit ner Uhrzeitbeschränkung für die Verbindung in BOINC) vorgeschlagen. Da du aber so einen unregelmässigen Internet-Zugang hast ist das wohl die beste Lösung

Zitat von WBT112

Dann hat sich mein 4-Seiten langes Shell-Skript ja erledigt

Oh, das hätte ich jetzt so gerne gesehen...

Nochmal Danke an alle die Interesse an meinem (eher ungewöhnlichen) Problem hatten. Besonders an pschoefer für die unerwartet einfache Lösung.

Schönen Tag noch, Grubix.


PS: Jetzt ist die Funktion nicht mehr undokumentiert, zumindest hier im Wiki...