In article <1tihg1hs19vv51ofh79ebivmngi5h672h1@4ax.com>,
Louis Holleman <louis@holleman.demon.nl> wrote:

On Sun, 21 Aug 2005 13:34:04 -0400, Roger
<Delete-Invallid.stuff.groups@tm.net> wrote:

I've found that running BOINC 4.45 causes the clocks on the three
machines running BOINC to run slow.  Shut BOINC down and the clocks

You haven't said that you are using Windows, but Windows has known
problems with time keeping.  It tends to lose clock interrupts when doing
disk I/O (Linux also has this problem, particularly on fast machines
where newer kernels use 1ms, rather than 10ms ticks - but Linux has
configuration options that can help mitigate this).  This time loss will
happen for any application that makes many disk accesses, and has been
reported for backup utilities (several minutes lost during a backup run!).

(Windows also isn't suitable for accurate timing because one can't
interpolate between clock ticks and because it has large scheduling
latencies that mean that timing on a loaded system jitters by about 20ms.)

BOINC should not be run with administrator privileges, so it should not
have the ability to directly compromise the clock and the use of Windows
is a sufficient reason for time keeping problems.

keep good time.  I did not have this problem with earlier versions of
BOINC.

I imagine it has started making more disk accesses.  Of course, a virus
is also likely to hit the disk hard.

The messing with the clocks which I have tied directly to the use of
BOINC 4.45 can really mess with some of the apps.

Another thing that contributes to timing slips on Windows is running
multi-media applications, as they cause the clock frequency to change,
greatly increasing the chance of lost interrupts.  You shouldn't run
time of day critical applications on Windows.  (I suppose its just
possible that BOINC enabled multi-media clocks not realising that
Windows can't cope with them.)

Frankfurt I believe, this machine takes a daily check and adjusts the
clock to what it should be. In turn, this machine feeds my LAN with
NTP broadcasts so the other puters keep up.

That's not a valid NTP configuration.  A valid NTP configuration would
be polling the server at an adaptive interval of between 64 and 1024
seconds.  You may have an SNTP configuration.  If W32Time is involved
anywhere (set time/sntp), you don't even have a valid SNTP implementation.

Boinc 4.45..... During this period the average daily drift has been
4.323 secs.... and apart from some odd values here and there I can
really see no big changes during that period.

With real ntp software you can trim out constant drifts without even
having any servers.  Your 50 ppm is poor for a good motherboard but
really quite good for cheap one, which often have errors of up to about
200ppm.  With a real sever, ntpd will learn the static correction.