[ntp:questions] NTP v3 server, v4 client can't synch

Unruh unruh-spam at physics.ubc.ca
Wed Sep 9 17:53:51 UTC 2009

Romain Kang From: <romain at kzsu.stanford.edu> writes:


>I write with a concern from my day job, working on APM (application
>performance monitoring) devices for OPNET Technologies, Inc.  I'm
>attempting to help a customer who is using an NTP v3 server running
>under a VMware virtual machine.  The APM device (FreeBSD) polls the

I am sorry, but that is an poor place to be using ntp. A virtual machine
has really horrible timing characteristics and the ability to discipline
its clock is almost non-existent. What you need to do is to discipline
the server clock which has access to the hardware to discipline its
clock, and get your virtual machine to get its time from there. 

A VM is NOT the same as a real computer, and for timing it is useless. 

>server, but appears to give it no credence, prefering to wander off
>on its own until its own time is several minutes off.  Rebooting
>our device gives us a step correction with "ntpdate -b", so the v3
>server is apparently good enough for that purpose.

>As might be imagined, this is the sort of site where we have no
>choice except to try working with the existing plant.  There are
>about 10 APM devices running FreeBSD (ntpd 4.2.0-a) and none of
>them are able to peer with the designated server.  Yet the customer
>reports that they don't have trouble getting other NTP clients
>within their network to sync.

>The constraints imposed by the installation seem tight.  In
>addition to the NTPv3 service, the ntpq outputs below show high
>jitter, not surprising when a VM doesn't have any execution latency
>assurances.  The server reports stratum=7, which makes me wonder
>if the whole works are actually unsynchronized, but ntptrace times
>out while trying to discover more.

>- Continual, automatic step corrections are undersirable because they
>  will cause bogus measurements in the APM device.

>- Specifying NTP version 3 in the "server" line had no benefit.

>- Given that there's no synch with root, we're guessing
>  that attempting to peer the APM devices is probably futile.

>- Specifying a lower minpoll seems like it could magnify the effect
>  of the server jitter.

>Perhaps we want to clear out ntp.drift and set high minpoll/maxpoll?
>(E.g., minpoll 10 / maxpoll 14).

>Might the huff-'n-puff filter help negate the server jitter?

No. The problem is NOT with network delays. The problem is with the
clock. It is useless. This is like asking how in the world one can make
a $1 Mickey Mouse windup watch give accurate time. It cannot. The VM
clock is probably drifting out of the range of ntp's ability to fix it. 

You might try chrony ( far faster at converging) if you are running
linux or BSD, but I would not hold out much hope there either. You are
beating your head against a brick wall.

>Any other suggestions?

Get a real computer.
Get the underlying OS to discipline its clock and have your virtual
machine get its time from there. 

More information about the questions mailing list