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

Joseph Gwinn joegwinn at comcast.net
Thu Oct 21 03:34:04 UTC 2010

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 

> Your best bet would be to add a GPS source to your Windows PC, when you 
> might expect errors of less than 250 microseconds under stable running 
> (i.e. leave the PC on 24 x 7).  If you can't do that, PC Narvik suggests 
> you might get within +/- 1.5ms.  That's with a configuration file like:
> server A  iburst  maxpoll 5
> server B  iburst  maxpoll 5
> server C  iburst  maxpoll 5
> where A, B and C all have a GPS source.  All PCs on the same switch, so a 
> much better ping than 2ms.  You could reduce the maxpoll further to 4 (if 
> the server operator agrees) and get somewhat better performance, and 
> keeping the PCs in a stable temperature environment would also be likely 
> to help.  The bumps at 05:00 are when the heating comes on.

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

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 

> In my experience, changing the priority of NTP doesn't help a lot, but 
> most of my PCs are not CPU-bound.  But I have given the account the rights 
> to do that.

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 

Joe Gwinn

More information about the questions mailing list