I realize you said connected_frac is irrelevant, but is a negative value within the bounds of normality?
Well that looks pretty normal.
connected_frac is almost always -1 on *nix machines and often on other platforms as well. The code for determining it has never worked cross-platform properly and the value is not used for anything since it is still very unreliable.
OK, good. Is there any indication of the clock drifting off calibration rapidly? I once had a machine that would get about 2 hours out of sync within a day or so. A normal very small drift would not be a problem. I imagine.
Quote:
After restarting the client, WCG immediately began processing, having accumulated a short term debt of over 14000, and a long term debt of over 11000.
As John indicated, it may take a while for BOINC to sort itself out. I'd be tempted to observe over the next day or two. If the problem is due to clock drift and if BOINC starts normal swapping between projects it should then not revert to the bahaviour you described previously. If it does revert after a few cycles of normal swapping then time syncing is not the issue.
OK, good. Is there any indication of the clock drifting off calibration rapidly? I once had a machine that would get about 2 hours out of sync within a day or so. A normal very small drift would not be a problem. I imagine.
There seems to be no major drift as of yet. None that I can detect anyways.
Quote:
As John indicated, it may take a while for BOINC to sort itself out. I'd be tempted to observe over the next day or two.
So am I. Interestingly, the problem did not reassert itself last night. However, I will continue monitoring the situation over the next couple of days to be sure that the problem remains resolved.
After a few significant belches over the first 36 hours after stopping ntpd, BOINC has settled down and is continuing to process Einstein and WCG in normal fashion.
My sincere thanks to everybody who weighed in and helped troubleshoot this!
RE: 0.674916
)
Well that looks pretty normal.
connected_frac is almost always -1 on *nix machines and often on other platforms as well. The code for determining it has never worked cross-platform properly and the value is not used for anything since it is still very unreliable.
BOINC WIKI
BOINCing since 2002/12/8
RE: I halted ntpd so it was
)
OK, good. Is there any indication of the clock drifting off calibration rapidly? I once had a machine that would get about 2 hours out of sync within a day or so. A normal very small drift would not be a problem. I imagine.
As John indicated, it may take a while for BOINC to sort itself out. I'd be tempted to observe over the next day or two. If the problem is due to clock drift and if BOINC starts normal swapping between projects it should then not revert to the bahaviour you described previously. If it does revert after a few cycles of normal swapping then time syncing is not the issue.
Cheers,
Gary.
RE: OK, good. Is there any
)
There seems to be no major drift as of yet. None that I can detect anyways.
So am I. Interestingly, the problem did not reassert itself last night. However, I will continue monitoring the situation over the next couple of days to be sure that the problem remains resolved.
RE: Interestingly, the
)
That sounds pretty hopeful! Let us know how it goes :).
Cheers,
Gary.
After a few significant
)
After a few significant belches over the first 36 hours after stopping ntpd, BOINC has settled down and is continuing to process Einstein and WCG in normal fashion.
My sincere thanks to everybody who weighed in and helped troubleshoot this!