[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
>> This is the performance I see:
>> 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
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
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
> Joe Gwinn
Yes, if the CPU loading is heavy I can quite believe that.
More information about the questions