[ntp:questions] What level of timesynch error is typical on Win XP?

David J Taylor david-taylor at blueyonder.co.uk.invalid
Thu Oct 21 07:05:44 UTC 2010

"Joseph Gwinn" <joegwinn at comcast.net> wrote in message 
news:joegwinn-DA4B7B.23340420102010 at news.giganews.com...
> In article <i9mqek$trl$1 at news.eternal-september.org>,
> "David J Taylor" <david-taylor at blueyonder.co.uk.invalid> wrote:
>> > I have a small network of Windows XP (64 bit) running simulations, 
>> > with
>> > NTPv4 running on all the boxes and using a GPS-based timeserver on 
>> > the
>> > company network.  The ping time to the server is 2 milliseconds from 
>> > my
>> > desk, but I'm seeing random time errors of order plus/minus 5 to 10
>> > milliseconds, based on loopstats data.
>> >
>> > This level of timesynch error is OK for the simulation, but still 
>> > that's
>> > a lot of error.  I get far better on big UNIX boxes.
>> >
>> > The question is if this level of error is reasonable, given the 
>> > setup.
>> > I know that timekeeping under Windows is not optimum, but cannot 
>> > change
>> > the OS, so the question is if I have gotten things as good as they 
>> > can
>> > be, or should I dig deeper.  One thing that comes to mind is to raise
>> > the priority of the NTP daemon to exceed that of the simulation
>> > software.
>> >
>> > Thanks in advance,
>> >
>> > Joe Gwinn
>> Joe,
>> This is the performance I see:
>>   http://www.satsignal.eu/mrtg/performance_ntp.php
>> The XP systems are:
>>   Feenix: GPS-synched
>>   Narvik: LAN-synced to Pixie (FreeBSD with GPS source)
> These are all over the place.  Both hardware and OS seem to matter, by a
> lot.

Hardly "all over the place"!  Feenix is well within a milliseconds, and 
Narvik just within a millisecond, and programs on that OS can only read 
the system time with ~16ms precision.

> I can't add a GPS source, and I can't really control temperature.

So you need to keep the polling interval short.

> I don't think that iburst is the issue, because the randomness persists
> for at least a week, long after the iburst transients will have died
> down.

I never said iburst was an issue, just that the systems will need to be on 
for several hours before best accuracy is achieved.  It's a pity that NTP 
doesn't have a faster initial convergence.

> My experience is the same. for average behaviour.  But for use in
> realtime, running the daemon at high realtime priority greatly reduces
> the tails of the probability distribution of response times and/or clock
> offsets.
> Joe Gwinn

Yes, if the CPU loading is heavy I can quite believe that.


More information about the questions mailing list