Watch run time and CPU time. nothing was changed in settings.
Actually not very strange at all :-).
You need to click on the taskID for your task and have a read through the stderr output text that was returned to the project. Here is the relevant bit right down near the end of the output. Note that there is a limit on what is returned so you can't see the entire file. Approximately the first half is missing and the file starts just as checkpoint 23 (out of 50) was being written.
Quote:
.....
% Time spent on semicoherent stage: 578 s
% Starting coherent stage.
% Time spent on coherent stage: 137 s % checkpoint written: skypoint 49
% Path to ephemeris file: ../../projects/einstein.phys.uwm.edu/JPLEPH
% Starting barycentering for sky point 50 / 50
% Creating FFT plan.
% Starting semicoherent stage.
% Status 1/83 ( 5 s)
% Status 2/83 ( 5 s)
% Status 3/83 ( 5 s)
% Status 4/83 ( 5 s)
% Status 5/83 ( 5 s)
% Status 6/83 ( 5 s)
% Status 7/83 ( 5 s)
% Status 8/83 ( 5 s)
% Status 9/83 ( 5 s)
% Status 10/83 ( 5 s)
% Status 11/83 ( 5 s)
% Status 12/83 ( 5 s)
% Status 13/83 ( 5 s)
% Status 14/83 ( 4 s)
% Status 15/83 ( 4 s)
% Status 16/83 ( 4 s)
% Status 17/83 ( 4 s)
% Status 18/83 ( 4 s)
% Status 19/83 ( 5 s)
% Status 20/83 ( 5 s)
% Status 21/83 ( 5 s)
% Status 22/83 ( 5 s)
% Status 23/83 ( 5 s)
% Status 24/83 ( 6 s)
% Status 25/83 ( 5 s)
% Status 26/83 ( 5 s)
% Status 27/83 ( 6 s)
% Status 28/83 ( 5 s)
% Status 29/83 ( 5 s)
% Status 30/83 ( 6 s)
% Status 31/83 ( 5 s)
% Status 32/83 ( 5 s)
% Status 33/83 ( 5 s) 07:30:39 (2895): [normal]: This Einstein@home App was built at: Aug 30 2011 14:23:52
% Path to ephemeris file: ../../projects/einstein.phys.uwm.edu/JPLEPH
% Starting barycentering for sky point 50 / 50
% Creating FFT plan.
% Starting semicoherent stage.
% Status 1/83 ( 6 s)
% Status 2/83 ( 5 s)
% Status 3/83 ( 5 s)
% Status 4/83 ( 5 s)
....
I've made bold a couple of key bits. The first bit shows the writing of the 49th checkpoint (out of 50) and the starting of work on checkpoint 50. Processing is almost done (98% complete) with just one stage to go. For some reason before completion of that final stage, the app was restarted and checkpoint 49 was read in from disk. See the second bold bit. The run time was just 750 secs for this last 2% and that's what got recorded instead of the total run time. It seems that restarting the app causes the original runtime to be discarded or reset to zero for some reason. I'm sure I've seen this behaviour before - perhaps it's something to do with Linux. If one checkpoint takes 750 secs you can work out an estimate of the true runtime - something like 50x750=37.500 secs which fits pretty well with the recorded CPU time.
If you think there is something funny with a particular task, it's always useful to browse what is returned to the project to see if there is relevant information there.
Very strange!!!
)
Who knows, this may be useful in time travel.
Always take a towel with you.
)
Always take a towel with you. *chrchr*
RE: http://einstein.phys.uw
)
Actually not very strange at all :-).
You need to click on the taskID for your task and have a read through the stderr output text that was returned to the project. Here is the relevant bit right down near the end of the output. Note that there is a limit on what is returned so you can't see the entire file. Approximately the first half is missing and the file starts just as checkpoint 23 (out of 50) was being written.
I've made bold a couple of key bits. The first bit shows the writing of the 49th checkpoint (out of 50) and the starting of work on checkpoint 50. Processing is almost done (98% complete) with just one stage to go. For some reason before completion of that final stage, the app was restarted and checkpoint 49 was read in from disk. See the second bold bit. The run time was just 750 secs for this last 2% and that's what got recorded instead of the total run time. It seems that restarting the app causes the original runtime to be discarded or reset to zero for some reason. I'm sure I've seen this behaviour before - perhaps it's something to do with Linux. If one checkpoint takes 750 secs you can work out an estimate of the true runtime - something like 50x750=37.500 secs which fits pretty well with the recorded CPU time.
If you think there is something funny with a particular task, it's always useful to browse what is returned to the project to see if there is relevant information there.
Cheers,
Gary.