All those tasks ended with Exit status 197 (0xc5) Maximum elapsed time exceeded.
Gruß,
Gundolf
This is probably a consequence of what I've reported here.
Because the crunch time estimate of affected tasks is way too low, BOINC will interfere and terminate the processing since it thinks crunching is taking way too long. If Bernd 'fixes' things in the DB and the 'fixed' estimates can be communicated to the client, maybe this can be retrieved - I don't know how this will play out.
It's also a bit strange for the OP because supposedly shorter tasks with the previous app were taking >12ksecs run time and yet the new tasks are failing at pretty much exactly 4706secs - a much shorter value. I don't understand that and unfortunately I don't have time to delve deeper.
If you have 'new and 10x longer' tasks but they're not showing a much longer estimate than previous values, you should probably abort them to stop wasting crunch time and ending up with a 'Max elapsed time exceeded' type result.
EDIT: My take is that 'new and 10x longer' means tasks for the V1.09 app from the point of initial release up to whenever Bernd finally 'fixed' things. If you have sufficient V1.04 ('old') work on hand for the time being, it might be prudent to wait for more details about exactly when the new but 'fixed' tasks started being issued and if there is any other option (other than drastic surgery on the state file entries) to correct the problem with issued tasks instead of just aborting them.
Only errors in FGRP v1.09
)
All those tasks ended with Exit status 197 (0xc5) Maximum elapsed time exceeded.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Yes, I think that might
)
Yes, I think that might happen soon on my PIII 800MHz (looks like about 5 days runtime per task).
I concur. I have six tasks
)
I concur. I have six tasks that have errored out at 'maximum runtime' of around 20 hours, and several more that look like they're headed that way.
http://einsteinathome.org/account/tasks&offset=0&show_names=1&state=5&appid=21
RE: All those tasks ended
)
This is probably a consequence of what I've reported here.
Because the crunch time estimate of affected tasks is way too low, BOINC will interfere and terminate the processing since it thinks crunching is taking way too long. If Bernd 'fixes' things in the DB and the 'fixed' estimates can be communicated to the client, maybe this can be retrieved - I don't know how this will play out.
It's also a bit strange for the OP because supposedly shorter tasks with the previous app were taking >12ksecs run time and yet the new tasks are failing at pretty much exactly 4706secs - a much shorter value. I don't understand that and unfortunately I don't have time to delve deeper.
If you have 'new and 10x longer' tasks but they're not showing a much longer estimate than previous values, you should probably abort them to stop wasting crunch time and ending up with a 'Max elapsed time exceeded' type result.
EDIT: My take is that 'new and 10x longer' means tasks for the V1.09 app from the point of initial release up to whenever Bernd finally 'fixed' things. If you have sufficient V1.04 ('old') work on hand for the time being, it might be prudent to wait for more details about exactly when the new but 'fixed' tasks started being issued and if there is any other option (other than drastic surgery on the state file entries) to correct the problem with issued tasks instead of just aborting them.
Cheers,
Gary.