Oracle ZFS Storage ZS3-2
 
Solaris Operating System
 

PLA-Support>Sun Systems>SAND>Network>SN-SND: Sun Network NTP
 
_Old GCS Categories>Sun Microsystems>Operating Systems>Solaris Network
 

Applies to:

Symptoms

Host does not remain in sync with time server

Cause

Time server constantly increases dispersion until it is out of bounds

Solution

Enter the Main Content

Symptoms
Hosts using Microsoft Windows NTP servers as time sources are not in sync. If you restart the xntpd daemon on the host, time will be in sync for a while, then the problem re-appears.


Resolution
The problem is caused by the WINDOWS NTP server and the "Clock dispersion" field in the NTP packet.

What is "Clock dispersion"?

Here is the definition from NTP specs:

"....NTP is designed to produce three products: clock offset, roundtrip delay
and dispersion, all of which are relative to a selected reference clock......

....Dispersion represents the maximum error of the local clock relative to the
reference clock.....

....They provide not only precision measurements of offset and delay, but also
definitive maximum error bounds, so that the user interface can determine not
only the time, but the quality of the time as well....."

Why does the "Clock dispersion" value bring NTP client out of sync?

This happens because the dispersion returned from the servers is slowly increasing in value. Once the value gets over 1 second, xntpd declares the server packets invalid.

Relief/Workaround

Configure other time servers that do not exhibit this behavior.

If you really must use Windows time servers, check that "LocalClockDispersion" is not adding significant dispersion like 10 seconds! See https://technet.microsoft.com/en-us/library/cc773263%28v=ws.10%29.aspx

Solaris 11 and Solaris 10 Update 8 and greater, provide NTPv4. The NTPv4 daemon will enforce this behavior and have a lesser tolerance for the high dispersion value.

In NTPv4 there is a workaround to avoid the Windows Server dispersion behavior. It is to edit the /etc/inet/ntp.conf file adding the option:

tos maxdist 12.0

That would allow a dispersion value up to 12.nnnn in NTP packets.

If a higher dispersion is detected from the Windows NTP Server it can be set to a higher value, ie., 15.0 for a dispersion value up to 15.nnnnn being received.

Then disable and enable the ntp Service:

Solaris 11:
svcdam disable ntp
svcadm enable ntp

Solaris 10 Update 8 and greater:
svcdam disable ntp4
svcadm enable ntp4

Additional Information
How to verify that you are hitting this problem
Snoop the NTP client:

# snoop -o /var/tmp/snoop.out -d <interface>

Then use the command snoop -v -i snoop.out | grep dispersion.

When the problem is present you will see something like this:

NTP:  Synchronizing dispersion = 0x0011.d993  (17.849899)
NTP:  Synchronizing dispersion = 0x0011.d993  (17.849899)

As long as this value is less than or equal to 1 second, then all NTP packets will be considered valid, otherwise, as in this example, the packets will be rejected.

Bear in mind, NO ERRORs will be found anywhere when this problem occurs.

Product
Solaris 10 Operating System
Solaris 9 Operating System SPARC Platform Edition
Solaris 8 (Europe/Asia)

clock dispersion, ntp, date out of sync, time out of sync, windows server
Previously Published As
84494

Change History
Date: 2006-03-02
User Name: 97961
Action: Approved
Comment: - Converted to STM formatting for better readability
- Made simple sentence/grammatical corrections
Version: 3
Date: 2006-03-02
User Name: 97961
Action: Accept

This solution has no attachment