[ntp:questions] how did ntp service set the maxallowphaseoffset

Martin Burnicki martin.burnicki at meinberg.de
Mon Nov 25 14:36:19 UTC 2013

xiaoniao112233 at gmail.com wrote:
 > hello :
 > I had recently start a work about ntp service ,my friends and me use
 > windows and linux to sync time in ntp.we could use w32time service to
 > sync linux in ntp.

I hope the Linux machine is the NTP server, and your Windows machine is 
the NTP client. Linux and other Unix-like systems are usually much 
better timekeepers than Windows is.

 > In windows we could I found that in the registry:
 > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\
 > MaxAllowedPhaseOffset may be could set the offset time between the
 > local time and the server that they will be synchronize. If out of
 > range of MaxAllowedPhaseOffset in seconds ,they synchronize,otherwise
 > not. But I have a question that Is there a paremeter in ntp service
 > that control the offset like in registry above in windows.

As has been noted by others here, ntpd tries to slew the system time 
smoothly if the estimated time difference is below a certain limit, and 
just steps the system time if if the determined offset exceeds this 
limit for some time. The limit is usually 128 ms, but can be changed.

Unfortunately you don't tell which Windows version and which version of 
the NTP service you are using.

If you are encountering problems getting the Windows time adjusted 
properly by ntpd then a a Windows bug can be the reason why.

Some Windows versions don't apply small time adjustments to the system 
time at all. For example, if NTP applies an adjustment less than 16 
ticks to the Windows time this is simply ignored by Windows. However, 
NTP expects the adjustment to have some effect, but if there is no 
effect then the next time comparison yields a much larger difference 
than expected, and thus causes another adjustment which is probably 
larger than necessary. As a summary this can cause large swings in the 
time adjustment values.

A developer version of the NTP package contains a workaround for this 
Windows bug. The report and fix are discussed here:

NTP Bug 2328 - Vista/Win7 time keeping inaccurate and erratic

The bug report contains a link to the Microsoft support web page 
explaining the bug:
SetSystemTimeAdjustment May Lose Adjustments Less than 16

Even though the MS report only mentions Windows 7, the Windows Server 
2008 kernel is similar to Windows 7 and has probably the same bug. So if 
you want to give it a try you can download a developer version of the 
NTP package which includes a workaround here:

You should try the release version first. Just unzip the ZIP archive, 
stop the NTP service, copy all extracted files over the files in your 
NTP installation directory (e.g. C:\Program Files (x86)\NTP\bin\), and 
restart the NTP service.

Also all newer development versions of the NTP binaries should include this.

We have found that this version has greatly improved the resulting 
accuracy on Windows 7 and Windows Server 2008 installations.

Please note under Windows you should configure all upstream servers with 
a line reading

server aa.bb.cc.dd iburst minpoll 6 maxpoll 6

where aa.bb.cc.dd has to be replaced with the host name or IP address of 
your NTP server.

Please don't use polling intervals below 6 with the developer version 
since this prevents the workaround from working correctly as discussed 
in the bug report.

Also, if you don't limit the upper bounds of the polling interval by 
"maxpoll 6" you may run into this bug:

NTP Bug 2341 - ntpd fails to keep up with clock drift at poll > 7

On the other hand, the developer version above configured with regard to 
the hints above has fixed the timekeeping and significantly increase the 
time accuracy in a number of installations of Windows 7 and Windows 
server 2008.

Hope this helps.

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list