What client version are you running?

The 6.2 client should not be displaying this behavior when smallish. Not seen it for a very very long time though Windows is permitted to adjust based on internet time. Also associated with security software interference, an FAQ on this found in the Start Here forum.

It upsets scheduling/statistics if very large adjustments are made, mostly when changing dates months in past or future.

YEAH, Finally I got my Gold Badge by Project Nutritious Rice for the World and now I look that I got my Ruby Badge, before the Project Nutritious Rice for the World was finished.


Greatings to all
[B@P]SEARCHER

If you meant me, it was (and still is) running 6.2.28 - only my fedora machines are not running the "WCG recommended" versions here. That's because 6.10.25 is in the regular Updates repository and I got tired of unchecking the BOINC files after clicking Select All in the yellowdog update manager extended (yumex).

I was using an external NTP program because I didn't know then I could tweak HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\SpecialPollInterval to 86400 (seconds) to make the windows NTP client update once per day instead of once per week (default value is 604800 seconds).
I also narrowed the change-window it would accept using the MaxPosPhaseCorrection and MaxNegPhaseCorrection values in
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\ - with each set at 5400 (seconds) if the NTP client tries to alter the time +/- more than 90 minutes, XP rejects the change; The external client I was using did not have an 'insanity check' like that. :-|

If I recall correctly, it was you that advised me NTP clients should have that capability, after one of my boxes received corrupt data and actually changed the date to outside the work unit expiration limits, causing them all to abort.

In any event, 6.2.28 was kicking out of crunch mode whenever the time was corrected on that machine, even if it was only by a few seconds. By the log clippings I saved about it on that machine (Athlon 2600+, 1GB RAM), it appears to have been happening with the FA@H task, mostly... but, I just triggered a manual update to see what would happen, and the time was adjusted 24 seconds:
2010-02-25 03:37:44 PM|WCG|Task R00581_79a2f05e8c7fb294054bde029ec50539_03_000_18 exited with zero status but no 'finished' file
2010-02-25 03:37:44 PM|WCG|If this happens repeatedly you may need to reset the project.
2010-02-25 03:37:44 PM|WCG|Restarting task R00581_79a2f05e8c7fb294054bde029ec50539_03_000_18 using rice version 617

Got blue with 2 years and two hours. So less than three hours overhead. Sorry, could it not minimize better... ;-) Now opting out from this project to leave you all the remaining WUs. Good luck!

I've never been happier losing a pool. :-)

My initial guestimates for sapphire are holding up though... another 9 days of crunching needed, so on the 10th or 11th I should be switching over to DDDT-2.