Workunits (allgemein)

Norman_RKN

Lt. Commander
Mitglied seit
26.08.2006
Beiträge
103
Renomée
17
hallo zusammen,

die regulären cmsearch WU werden leer laufen, da yoyo was umstellen/anpassen muss und lediglich cmsearch2 WU sind dann vorerst erhältlich.

TIP: wer also lieber die "normalen" cmsearch noch rechnen will sollte JETZT seinen workbuffer vergrößern ;)
.
EDIT :
.

in den letzten 4-5 h wurden die fast restlos abgegrast. ( 17.000 WU ) ;)

wer sich wundert über das lange pending dem kann ich sagen... die validatoren sind am "kotzen" und rennen auf hochtouren.
die cmsearch2-zip archive die oft mehrere kleine WU beinhalten müssen vom validator geöffnet werden und einzeln betrachtet werden und das hält anscheinend doch ganz schön auf.
der server hat jetzt mehrere validatoren gleichzeitig angeworfen und somit sollte das jetzt schon etwas schneller gehen.
 
Zuletzt bearbeitet:
die verbleibenden cmsearch WU werden immer noch mit initial replication 4 rausgehauen statt mit 2.
4 leute bekommen sie daher gleichzeitig und wie ihr sicherlich bemerkt habt werden einige WU, die noch nicht begonnen haben bei euch zu rechnen, aus eurem boincpuffer abgebrochen wenn 2 validierte auf dem server vorliegen.
wie schon (in anderem thread) erwähnt wird so versucht, so schnell wie möglich, die "alte" cmsearch-queque des servers abzuarbeiten damit änderungen am system beginnen können.
u.a. anpassung der apps und laufzeitauswahl der WU in den berechnungseinstellungen bis max. 20h und über 20h+... (später genannt cmsearch S für short und cmsearch XXL für lange laufzeit der WU.)

die cmsearch WU laufen im moment mit höchster priorität.
die cmsearch2 mit zweithöchster
und cmc mit niedrigster.
(für die die es wundert warum so massiv cmsearch eintrudeln trotz anderer app/WU-auswahl) ;)
 
Zuletzt bearbeitet:
so die cmsearch sind (vorerst) komplett durch und nur noch cmsearch2 sind in der pipeline wie ich von der projektleitung erfahren habe. (und cmc)

um neue cmsearch WU zu generieren bräuchte rna world allerdings etwas mehr rechenpower unter linux x64.

die cmcalibrate (cmc) WU sind grundlage für alle cmsearch (cms).
die cmc sind imports aus einer oder mehrerer gendatenbanken die es aber vorher für cms zu kalibrieren gilt. die hat Michael ausgewählt, u.U. mit parametern versehen und müssen jetzt berechnet werden und aus deren ergebnisse Michael neue wahnsinnig viele cms "herstellen" kann.

das "blöde" daran ist, rna world hat ziemlich wenig x64 linux am start und die wissenschaftlichen anwendungen wurden unter linux entwickelt.
(es gibt auch für win und mac die gleiche anwendung).
um aber 101% sicher zu gehen, dass die sehr wichtigen cmc-resultate ( die grundlage für alles andere sind) stimmen, wird diese unter linux berechnet.

wer also noch x64 linux kapazitäten frei hat bitte NUR cmc vorläufig auswählen und keine arbeit von anderen apps zulassen. ( kann dauern bis man WU erhält bei den paar usern aber sie kommen ;) )
Michael wartet schon ganz nervös auf die fertigen CMC resultate damit er abermillionen cms WU generieren kann.
 
also ich habe mal bei mir nur die cmc erlaubt, habe auch noch genügend andere cms im puffer, soll ich die abbrechen? also die unbearbeiteten mein ich nat. allerdings habe ich auch gerade die meldung bekommen ich soll doch auch andere projekte zulassen, da für cmc gerade nix vorliegt *noahnung* ;D
 
würd die erst abbrechen wenn du genügend cmc-wu gesammelt hast. ("leerlauf-gefahr" ;) )
die kommen schon aber nur tröpfchenweise und das dauert etwas. ;)

sind noch etwas über 1000 WU zu zeit.
 
Michael wartet schon ganz nervös auf die fertigen CMC resultate damit er abermillionen cms WU generieren kann.

Habe das auch mal umgestellt. Mal schauen, betreibe das ganze grade via Fernwartung und hoffe das kommt auch irgendwann so beim Rechner an.
 
Auf meinen drei Linux x64 Kisten (2* AMD, 1*Intel) erhalte ich seit heute morgen keine cmc Workunits mehr. Laut Statusseite sollten noch etwa 2700 vorhanden sein.
Interessanterweise ist heute Vormittag die Anzahl der noch nicht Verschickten stark angestiegen.
 
das könnte daran liegen, dass die WU-queque mit cms2 WU gefüllt ist aufgrund höherer benutzeranzahl für diese anwendung und nur einige wenige cmc in der versandschleife stecken. ?!
mmh, nicht so gut.

die anzahl der ungesendeten cmc ist deshalb so nach oben gesprungen, weil die initial replication von 2 auf 4 erhöht wurde. 4 rechner bekommen also die WU statt bisher nur 2.
geht dann etwas schneller in der regel die serie fertig zu berechnen.
 
kurze info zur cmsearch2-app:

yoyo schrieb:
Die neue cmsearch2 App hat schon einiges gebracht:
- keine kleinen WUs mehr, die den Server unter Stress setzen
- keine ganz ganz kurzen WUs mehr, die der Server selbst rechnen muss. Noch ca. 10.000 hat der Server allerdings noch vor sich.
- Da die WUs jetzt länger sind brauchen wir auch keinen großen Vorrat mehr in der Boinc DB vorzuhalten, was die DB beschleunigen sollte.

Also alles in Allem mehr CPU Power für den Server selbst.
Daher habe ich ihn jetzt auch erstmal an die cmcalibrate und cmsearch XXL gesetzt.

Zu beobachten gilt jetzt allerdings der Validator, der jetzt bis zu 200MB zu validieren hat. Bisher hatte ich davon mehrere laufen, damit der Rückstand abgebaut werden kann. Ich werden den jetzt wieder auf nur eine Instanz reduzieren.

yoyo

wie ihr sicherlich bemerkt habt werden die zeiten der apps (cmsearch s/xxl) noch nicht eingehalten.
das liegt daran, dass noch ca. 2,5k reguläre cms-WU abzuklappern sind (incl. ein paar wenige introns, deren laufzeit ja bekanntlich etwas laaaange ist) und bevor änderungen geschehen können eben diese weg sein müssen. ( sind inkompatibel zu den neuen anwendungen).
darum wird alles zumutbare erstmal in die cms2-wu eingespeist.

es wäre schön wenn die abgearbeitet sind, denn vom 1.4-30.04 könnte dann ein "allgemeines" race stattfinden, aber wie es im moment aussieht wird es knapp.
sieht nach vertagung aus.

danke für eure beachtliche rechenleistung die ihr dem projekt zukommen lasst *greater*
weiter so.
 
Bekomme gerade keine neuen WU's, gibts nen Anlass?
 
das liegt daran.
I doubled some old wus, to get these archives finished. But this means, that these tasks got the same HR class as the existing ones. So some HR-classes are now blocking the send queue and must be send first, before you get new work.
yoyo

ein paar linux 32-bit maschinen mehr würden gebraucht.
 
Zuletzt bearbeitet:
mein Rechner is auch zfetzn leer :(
zwangspause....
 
im moment scheint es irgendwelche probleme zu geben.
noch keine ahnung was los ist und warum keine WU nachkommen.

die cmc apps lässt Michael extra gerne auf linux laufen weil sie darauf entwickelt worden sind und will 100% sicher gehen keine "falschen fuffziger" in den ergebnissen zu haben auf dessen alles andere aufgebaut ist.
demnächst sollen aber weitere "gegenproben" mit windows erfolgen und bei erfolg öfters eingesetzt werden, weil einfach mehr rechpower unter win vorhanden ist.
für mac gibts die ebenfalls, aber da ist ebenfalls das problem des geringen durchsatzes.
mischen kann man die bislang noch nicht ohne weiteres wegen den HR-klassen.
 
Kurz zum MAC: Wenn da nicht bald Unterstützer in Schaaren kommen, werde ich überlegen, die MAC-Unterstützung für die Zukunft wieder einzustellen. Es macht nämlich wenig Sinn, für quasi niemanden Software bereit zu stellen.

Michael.
 
Heute ist eine meiner drei Introns endlich fertig geworden, erfolgreich.
Was mich etwas stutzig macht, ist die Laufzeit auf meinem AMD System im Vergleich zu den drei anderen Intel PCs, die diese WU deutlich schneller verarbeitet haben:

http://www.rnaworld.de/rnaworld/workunit.php?wuid=4495799

meine Laufzeit: X6 1055 ~479h

Laufzeit Q9550: ~239h (50% schneller)
Laufzeit Q6600 : ~267h (44% schneller)
Laufzeit i7 920: ~290h (39% schneller)

Vor allem im direkten Vergleich mit dem Q9550 sieht mein X6 alt aus!
 
Zuletzt bearbeitet:
liegt an der verwendeten Compiler-Software ...
 
Da wäre es ja fast besser ne AMD optimierte Anwendung (neben der für Intel) als eine für Mac.
 
Nee, Jungs. Da ist irgendwas oberfaul. Wieso ist da eine validierte WU mit 0 sec Runtime dabei?

Michael.
 
anscheinend wurde aus irgendeinem grund die runtime nicht übermittelt, aber dafür die cpu-laufzeit.
halte ich für eher unkritisch.
was die o.g. laufzeiten betrifft da bin ich skeptisch.
die anwendungen wurden auf verschiedenen systemen getestet und da sind offenbar keine großen abweichungen aufgetreten, sonst würden sofort bei unserem "obercompilator" die sirenen tönen.
es wurden verschiedene compiler und alle möglichen flags ausprobiert um beste performance der apps heraus zukitzeln.
da wird niemand benachteiligt ;)
 
Hmmm, die Validierung ist zu meiner Überraschung anscheinend OK.

anscheinend wurde aus irgendeinem grund die runtime nicht übermittelt, aber dafür die cpu-laufzeit.
halte ich für eher unkritisch.
...hängt mit der BOINC-Version zusammen, wie ich jetzt weiß. ;)

was die o.g. laufzeiten betrifft da bin ich skeptisch.
die anwendungen wurden auf verschiedenen systemen getestet und da sind offenbar keine großen abweichungen aufgetreten, sonst würden sofort bei unserem "obercompilator" die sirenen tönen.
es wurden verschiedene compiler und alle möglichen flags ausprobiert um beste performance der apps heraus zukitzeln.
da wird niemand benachteiligt ;)
Nein, die Intron WUs sind völlig unvorhersagbar bezügl. Laufzeiten und betreffendem Rechensystem. Hat nichts zu tun mit dem albernen Intel vs. AMD Quatsch.

Michael.
 
...
Nein, die Intron WUs sind völlig unvorhersagbar bezügl. Laufzeiten und betreffendem Rechensystem. Hat nichts zu tun mit dem albernen Intel vs. AMD Quatsch.

Michael.

Ich will hier auch nicht die AMD vs Intel Disskusion anfangen. Es wundert mich vielmehr, dass mein System im Vergleich zu den anderen drei so schlecht abschneidet. Vielleicht habe ich ja auch irgendwas falsch oder ungünstig konfiguriert! Die Introns sollten meiner Meinung auf ähnlichen Systemen die gleiche Laufzeit haben.
 
Oh neeeeiiiiiin.
Nun hat es meine beiden restlichen Introns erwischt: Error while computing

http://www.rnaworld.de/rnaworld/workunit.php?wuid=4496100
Report deadline: 12 Apr 2011 6:45:41 UTC
Abbruch: ~701,8h
Deadline BM: 23.03.
Laufzeit Q9505: ~664h
Laufzeit i7 920: ~811h

http://www.rnaworld.de/rnaworld/workunit.php?wuid=4496039
Report deadline: 17 Apr 2011 17:48:46 UTC
Abbruch: ~547h
Deadline BM: 28.03.
Laufzeit Q9505: ~670h
...

Sowie ich das aus der Ferne sehe, läuft der PC noch weiter und berechnet nun 6 Superlink WUs, ergo kein Stromausfall.
Der PC läuft seit über 30 Tagen fehlerfrei, eine Intron hat er nach ~479h auch fertig gerechnet! Was kann da schief gelaufen sein??
 
Vermutlich hat die Superlink Parallelrechnung zu einem Speichermangel geführt?

Michael
 
Zurück
Oben Unten