Host macht komische Sachen

[Ananas]

Noch so 'ne WU (3-Minuten fuer eine Intron = unmoeglich) : http://www.rnaworld.de/rnaworld/result. ... d=14911390

Der Rechner hat allerdings auch schon eine laengere fertig bekommen, macht also nicht nur Murks.

[Michael H.W. Weber]

Der Validator erkennt momentan nicht, wenn beim Dateitransfer was schieflief und er gar keine Ergebnisdateien erhalten hat.

Darf ich kurz fragen, wie Du darauf kommst, dass der Validator das nicht erkennt?

Und die wissenschaftliche Zuverlässigkeit leidet wohl auch etwas, wenn nur ein einziges der beiden Resultate vorhanden ist ohne daß der Validator das Fehlen des zweiten bemerkt...

Auch da wüßte ich gerne, woran Du diese Behauptung konkret festmachst.

Wir hatten vor längerer Zeit das Problem, dass der Validator zwei Ergebnisse mit 0 Bytes als korrekt validierte. Das wurde von Yoyo meines Wissens korrigiert.
Alles andere im Zusammenhang mit dem von Dir gesagten wäre mir jetzt eine (unangenehme) Neuigkeit, darum hake ich nach...

Michael.

[Ananas]

... Wir hatten vor längerer Zeit das Problem, dass der Validator zwei Ergebnisse mit 0 Bytes als korrekt validierte. ...

Ich will das mal etwas genauer beschreiben :

Es war nicht so, dass zwei 0-Bytes-Results, die naturgemaess identisch sein muessen, gegeneinander gueltig validiert wurden - was ja aus Validatorsicht sogar in Ordnung gewesen waere.

Vielmehr war ein Result korrekt (oder zumindest vollstaendig), das zweite hatte 0 Bytes und diese beiden wurden gegeneinander validiert - beide wurden als "valid" markiert.

Vermutlich wurde also nur die Gueltigkeit bis zum Ende des kuerzeren der beiden Results ermittelt, was (zumindest theoretisch und sofern kein zweiter Sicherheitsschritt greift) das Risiko beinhaltet, dass ein unvollstaendiges Result in der Datenbank landet.

Korrekt ist aber : Laut Yoyo kann das aber nicht mehr passieren, die Luecke wurde also behoben..

[yoyo]

Um noch konkreter zu sein, es wurde ein zip file zurückgeliefert, welches ein 0 Byte Result file enthielt.
yoyo

[Michael H.W. Weber]

OK, Danke Volker & Yoyo, dann ist das jetzt klar.

Michael.

[mweisensee]

Hallo!

Sorry, daß ich nicht eher geantwortet habe, aber ich hatte eine Woche Urlaub und kam erst gestern wieder.

Der Validator erkennt momentan nicht, wenn beim Dateitransfer was schieflief und er gar keine Ergebnisdateien erhalten hat.

Darf ich kurz fragen, wie Du darauf kommst, dass der Validator das nicht erkennt?

Schaut doch mal die WU 6329354 genauer an. Und sucht die Ergebnisdatei für meine Task (id 14915692). Ihr werdet sie nicht finden. Sie wurde nachweislich nicht gesendet, weil der berechnende Rechner gar keine Netzwerkverbindung hat. Boinc hatte sie aber nach dem fälligen Neustart intern als bereits hochgeladen markiert (und lokal gelöscht, konnte sie also gar nicht mehr senden) und somit das Ergebnis korrekt gemeldet. Und der Validator (wer sonst?) hat die (hoffentlich) existierende Datei der ersten Task mit meiner nicht vorhandenen verglichen und ist zu dem Schluß gekommen, daß das Ergebnis gültig ist. Warum der Validator das nicht erkennt, ist mir nicht bekannt, nur daß er es nicht erkennt.
(Wenn ihr meine Task zurück auf In Progress setzt, dann liefere ich die richtige Berechnung in ein paar Tagen/Wochen nach. Aber ich konnte ja schlecht so eine Behauptung aufstellen ohne sie vorher überprüft zu haben...)

Und die wissenschaftliche Zuverlässigkeit leidet wohl auch etwas, wenn nur ein einziges der beiden Resultate vorhanden ist ohne daß der Validator das Fehlen des zweiten bemerkt...

Auch da wüßte ich gerne, woran Du diese Behauptung konkret festmachst.

Ihr wollt alle WUs mit Quorum 2 berechnen lassen, weil es sonst nicht zuverlässig genug ist (hab ich in einem anderen Thread gelesen). Dem stimme ich zu, aber wie das Beispiel der obigen WU zeigt, ist das nicht gewährleistet, wenn es möglich ist, daß ein fehlendes Resultat validiert wird.
Hier gibt es teils extreme Abweichungen in der Berechnungszeit validierter WUs. Und wenn langsamere Rechner viel weniger Zeit für die Berechnung eines gültigen Resultats brauchen als schnellere (wie das Beispiel in meinem ersten Posting), ist die Berechnung entweder nichtdeterministisch (weiß ich nicht, würde aber erklären, warum die Validierung so großzügig ist) oder Boinc macht gelegentlich noch was falsch. Und das sollten wir ausschließen, sonst fiele es mir schwer, mich auf alle gewonnenen Resultate zu verlassen...
Ach ja, falls Ihr noch weitere Informationen braucht, sagt es mir bitte. Es wäre mir aber lieber, sie als PM zu schicken, solange dieser Validator-Bug nicht behoben ist. Fehler sollte man schließlich beheben, nicht ausnutzen.

Matthias

[yoyo]

Hallo!

Sorry, daß ich nicht eher geantwortet habe, aber ich hatte eine Woche Urlaub und kam erst gestern wieder.

Der Validator erkennt momentan nicht, wenn beim Dateitransfer was schieflief und er gar keine Ergebnisdateien erhalten hat.

Darf ich kurz fragen, wie Du darauf kommst, dass der Validator das nicht erkennt?

Schaut doch mal die WU 6329354 genauer an. Und sucht die Ergebnisdatei für meine Task (id 14915692). Ihr werdet sie nicht finden. Sie wurde nachweislich nicht gesendet, weil der berechnende Rechner gar keine Netzwerkverbindung hat. Boinc hatte sie aber nach dem fälligen Neustart intern als bereits hochgeladen markiert (und lokal gelöscht, konnte sie also gar nicht mehr senden) und somit das Ergebnis korrekt gemeldet. Und der Validator (wer sonst?) hat die (hoffentlich) existierende Datei der ersten Task mit meiner nicht vorhandenen verglichen und ist zu dem Schluß gekommen, daß das Ergebnis gültig ist. Warum der Validator das nicht erkennt, ist mir nicht bekannt, nur daß er es nicht erkennt.
(Wenn ihr meine Task zurück auf In Progress setzt, dann liefere ich die richtige Berechnung in ein paar Tagen/Wochen nach. Aber ich konnte ja schlecht so eine Behauptung aufstellen ohne sie vorher überprüft zu haben...)
Matthias

Das kann ich so bisher nicht nachvollziehen. In der Boinc DB steht dass Dein Result mit 140314 Bytes eingegangen ist:

Code: Alles auswählen

XML doc out 	

<file_info>
    <name>cms_GA-p[b-Lin64f-2]_1_Lactobacillus-casei-ATCC-334_CP000423.cir.EMBL_RF00177_SSU_rRNA_5_1358679723_1052_13_0</name>
    <nbytes>140314.000000</nbytes>
    <max_nbytes>1000000000.000000</max_nbytes>
    <md5_cksum>9ee30882c111f8258132c1f6b457ad02</md5_cksum>
    <url>http://www.rnaworld.de/rnaworld_cgi/file_upload_handler</url>
</file_info>
<file_info>
    <name>cms_GA-p[b-Lin64f-2]_1_Lactobacillus-casei-ATCC-334_CP000423.cir.EMBL_RF00177_SSU_rRNA_5_1358679723_1052_13_1</name>
    <nbytes>646.000000</nbytes>
    <max_nbytes>100000000.000000</max_nbytes>
    <md5_cksum>bdf3e6624b5dd23cde4b81fae50daf91</md5_cksum>
    <url>http://www.rnaworld.de/rnaworld_cgi/file_upload_handler</url>
</file_info>

Ich werd heute Abend nochmal auf dem Server danach suchen.

yoyo

[mweisensee]

Hallo,

vergleich doch mal die Länge/Prüfsumme der Ergebnisfiles für beide Tasks - die sollten schonmal abweichen.

[Ananas]

Hier haben wir auch einen seltsamen Fall :

http://www.rnaworld.de/rnaworld/result. ... d=14916634

Das kann eigentlich kein gueltiges Intron-Ergebnis sein, steht aber zur Validierung an (wartet auf Partner).

Mal im Auge behalten

[ChristianB]

Ich habe das Paket als auslaufend markiert. Es werden also keine neuen Aufgaben erzeugt. Das Result ist tatsächlich leer und der Validator wird das aber erst feststellen wenn ein zweites zum Vergleichen da ist. Bei den Introns ist die wahrscheinlichkeit hoch das dies ebenfalls leer ist, deshalb lasse ich das Paket auslaufen.

[Ananas]

... Bei den Introns ist die wahrscheinlichkeit hoch das dies ebenfalls leer ist ...

Gar nicht hoch, ich bin bei 20% und bisher habe ich auf der Kiste in letzter Zeit relativ wenig Probleme (auch mit Introns nicht), ich moechte es wenigstens versuchen Nachtrag : stderr.txt sieht bisher gut aus, keine Restarts.

Allerdings habe ich gerade auf meiner (pro Task) langsamsten Kiste gerade ein ziemlich extremes Teil bekommen, ob ich das durchkriege, bezweifle ich irgendwie (hier der Forecast) :

Code: Alles auswählen

...
# Pre-search info for CM 1: Intron_gpI
#
#                                  cutoffs            predictions     
#                            -------------------  --------------------
# rnd  mod  alg  cfg   beta     E value   bit sc     surv     run time
# ---  ---  ---  ---  -----  ----------  -------  -------  -----------
    1  hmm  fwd  loc      -    3669.057     0.00   0.5967  00:44:58.30
    2   cm  ins  loc  1e-015   15954.628     0.00   0.1743  2104:51:57.51
# ---  ---  ---  ---  -----  ----------  -------  -------  -----------
  all    -    -    -      -           -        -        -  2105:36:55.81 <==============================
#
#
# CPU time: 148.39u 00:02:28.39 Elapsed: 00:02:29

Seit da RNA laeuft, brechen alle paar Minuten alle anderen Threads mit Heartbeat-Fehler ab. Bin mal gespannt, was daraus wird.

[Ananas]

... Bei den Introns ist die wahrscheinlichkeit hoch das dies ebenfalls leer ist ...

Gar nicht hoch, ich bin bei 20% und bisher habe ich auf der Kiste in letzter Zeit relativ wenig Probleme (auch mit Introns nicht), ich moechte es wenigstens versuchen Nachtrag : stderr.txt sieht bisher gut aus, keine Restarts. ...

Fertig hab' ich ja ... trotzdem ist was seltsam :

http://www.rnaworld.de/rnaworld/workuni ... id=6329635

Fertig, Bestätigung nicht eindeutig (Host 106)

Es gibt ueberhaupt kein zweites Result, gegen das der Versuch einer Validierung haette passieren koennen, muesste also eigentlich "initial" sein - falls der Gegenpart bei der Validierung nicht das oben bereits erwaehnte war, das aber bereits ungueltig markiert ist :

http://www.rnaworld.de/rnaworld/result. ... d=14916634