Got another watchdog result due to reducing the run time, but this one did not get stuck and went on to complete as an error. This means that the stuck at 100% bug is only intermittently triggered by the watchdog.

In the longer term, when/if you have time, how much work would be involved in making the watchdog bark only when the run time was 4X the longest preference seen during the run? This would mean keeping track of the max_pref_runtime each time the code updated the run time in its memory. Please don't do this if it would be a lot of effort, but if it would be fairly easy it would re-instate the useful feature of being allowed to adjust the run time during the run.

I do this either when LHC has work, or immediately before system backups so I am not backing up half run Rosetta work, which would in any case be obsolete if the backups were ever needed.

River~~

I have two PC's running this - both have had pending units which remain for
over a week now and all I get is ...

rosetta@home - 2007-02-14 09:52:53 - Sending request to scheduler: https://boinc.bakerlab.org/rosetta_cgi/cgi
rosetta@home - 2007-02-14 09:52:59 - Scheduler RPC to https://boinc.bakerlab.org/rosetta_cgi/cgi succeeded
rosetta@home - 2007-02-14 09:52:59 - SCHEDULER_REPLY::parse(): bad first tag <?xml version="1.0" encoding="ISO-8859-1" ?>
rosetta@home - 2007-02-14 09:52:59 - Can't parse scheduler reply
rosetta@home - 2007-02-14 09:52:59 - Deferring communication with project for xx minutes and xx seconds

I put the xx in at the end as it varies between hours and even days!
Depending on reboots or not.

Whats going on?? (running 5.45)

---