f



WIndows-7 polling intervals, and Windows-10

I recall that setting maxpoll 7 is recommended (by Martin, IIRC) for 
Windows-7 where a system call limits the precision with which the clock 
rate can be set.

Has anyone tested Windows-10 to see whether the same limitation and 
hence the same recommendation apply?  Has that OS bug been fixed?
-- 
Thanks,
David
Web: http://www.satsignal.eu
0
David
11/16/2016 3:01:11 PM
comp.protocols.time.ntp 4895 articles. 2 followers. Post Follow

7 Replies
231 Views

Similar Articles

[PageSpeed] 1

David,

David Taylor wrote:
> I recall that setting maxpoll 7 is recommended (by Martin, IIRC) for
> Windows-7 where a system call limits the precision with which the clock
> rate can be set.

No. There are 2 different points:

The maximum poll interval has been proposed here:
"ntpd fails to keep up with clock drift at poll>7"
http://bugs.ntp.org/show_bug.cgi?id=2341

The limited precision is due to this problem:
"SetSystemTimeAdjustment May Loose Adjustments Less than 16"
http://support.microsoft.com/kb/2537623

ntpd's workaround for this bug requires that the poll interval doesn't
drop below 6, thus the suggestion for minpoll 6.

AFAIK the workaround for the latter issue is only in effect for Windows
Vista / windows 7 and the associated Windows server versions, so it is
not in effect for Windows 10.

> Has anyone tested Windows-10 to see whether the same limitation and
> hence the same recommendation apply?  Has that OS bug been fixed?

With the performance you have today on networks, even via the internet,
I think a shorter polling interval is good in general. I know there are
other opinions, but my tests have shown this is correct in most cases.

Potential reasons for the advantage of a longer poll interval is that in
theory this allows a more accurate measurement of the time offset.

E.g. if you adjust your wristwatch accurately and then compare the time
again only one hour later you probably won't see any difference, but if
you look again after one day you see if the wristwatch is then off by
one second, or by 2.

However, this works only well if your wristwatch drifts at the same rate
all the time. This may have been the case with old mainframe servers
which had good oscillators onboard, but normal PCs usually have cheap
xtals only.

The frequency of these xtals usually changes significantly due to
changes in the ambient temperature, and the temperature inside and
outside the PC housing can change frequently, when the air condition
kicks in or out, when the CPU changes from idling to high load, etc.

So if the frequency changes during long poll intervals then there's no
increased accuracy, and my observations show that the system time is
adjusted smoother if the polling interval is kept low.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany
0
Martin
11/17/2016 10:12:34 AM
On 17/11/2016 10:12, Martin Burnicki wrote:
> David,
>
> David Taylor wrote:
>> I recall that setting maxpoll 7 is recommended (by Martin, IIRC) for
>> Windows-7 where a system call limits the precision with which the clock
>> rate can be set.
>
> No. There are 2 different points:
>
> The maximum poll interval has been proposed here:
> "ntpd fails to keep up with clock drift at poll>7"
> http://bugs.ntp.org/show_bug.cgi?id=2341
>
> The limited precision is due to this problem:
> "SetSystemTimeAdjustment May Loose Adjustments Less than 16"
> http://support.microsoft.com/kb/2537623
>
> ntpd's workaround for this bug requires that the poll interval doesn't
> drop below 6, thus the suggestion for minpoll 6.
>
> AFAIK the workaround for the latter issue is only in effect for Windows
> Vista / windows 7 and the associated Windows server versions, so it is
> not in effect for Windows 10.
>
>> Has anyone tested Windows-10 to see whether the same limitation and
>> hence the same recommendation apply?  Has that OS bug been fixed?
>
> With the performance you have today on networks, even via the internet,
> I think a shorter polling interval is good in general. I know there are
> other opinions, but my tests have shown this is correct in most cases.
>
> Potential reasons for the advantage of a longer poll interval is that in
> theory this allows a more accurate measurement of the time offset.
>
> E.g. if you adjust your wristwatch accurately and then compare the time
> again only one hour later you probably won't see any difference, but if
> you look again after one day you see if the wristwatch is then off by
> one second, or by 2.
>
> However, this works only well if your wristwatch drifts at the same rate
> all the time. This may have been the case with old mainframe servers
> which had good oscillators onboard, but normal PCs usually have cheap
> xtals only.
>
> The frequency of these xtals usually changes significantly due to
> changes in the ambient temperature, and the temperature inside and
> outside the PC housing can change frequently, when the air condition
> kicks in or out, when the CPU changes from idling to high load, etc.
>
> So if the frequency changes during long poll intervals then there's no
> increased accuracy, and my observations show that the system time is
> adjusted smoother if the polling interval is kept low.
>
> Martin

Thanks for that detailed reply, Martin.

In summary, as the normal minpoll is 6, there's no need to set anything 
there, except that putting it into a configuration makes sure that 
Vista/Win-7 systems work as expected.

Having the maxpoll at 7 may improve timekeeping for today's typical 
systems (particularly Windows desktop or tablet PCs) so leave it as a 
default recommendation.

I agree and am happy with that, thanks!

-- 
Cheers,
David
Web: http://www.satsignal.eu
0
David
11/17/2016 11:18:03 AM
On 2016-11-17, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
> David,
>
> David Taylor wrote:
>> I recall that setting maxpoll 7 is recommended (by Martin, IIRC) for
>> Windows-7 where a system call limits the precision with which the clock
>> rate can be set.
>
> No. There are 2 different points:
>
> The maximum poll interval has been proposed here:
> "ntpd fails to keep up with clock drift at poll>7"
> http://bugs.ntp.org/show_bug.cgi?id=2341
>
> The limited precision is due to this problem:
> "SetSystemTimeAdjustment May Loose Adjustments Less than 16"
> http://support.microsoft.com/kb/2537623
>
> ntpd's workaround for this bug requires that the poll interval doesn't
> drop below 6, thus the suggestion for minpoll 6.
>
> AFAIK the workaround for the latter issue is only in effect for Windows
> Vista / windows 7 and the associated Windows server versions, so it is
> not in effect for Windows 10.
>
>> Has anyone tested Windows-10 to see whether the same limitation and
>> hence the same recommendation apply?  Has that OS bug been fixed?
>
> With the performance you have today on networks, even via the internet,
> I think a shorter polling interval is good in general. I know there are
> other opinions, but my tests have shown this is correct in most cases.
>
> Potential reasons for the advantage of a longer poll interval is that in
> theory this allows a more accurate measurement of the time offset.

Not really. The longer poll intervals allow a better estimate of the
drift rate of the clock -- assuming it is constant). So short poll
intervals keep the actuall offset of the clock closer to zero, long poll
intervals keep the drift rate close to zero, but generally the offset
worse. Depending on the noise there is an optimum (allan intercept).
HOwever in general computers do not have gaussian random noise in
either. The drift rate is internal temperature dependent, and that
depends on how hard the cpu is working (as well as the external
temperature), and that is highly non-guassian. The offsets are also
non-gaussian as are the measurement errors (getting rid of "popcorn"
noise is a crude attempt to get rid of some of this non-gaussian noise).
I tend to agree with the "shorter poll is better" as well, except when
you know that your system will go offline at times and you want to make
sure that it survives those disconnects reasonably well (low drift).

Measurements I made show that the clock rate fluctuates during the day,
because the computers work harder during the day. One of the reasons
that chrony does so much better than ntpd in keeping the offset low is
its much faster ( and very non-linear response) to those sorts of
non-gaussian noise. 
>
> E.g. if you adjust your wristwatch accurately and then compare the time
> again only one hour later you probably won't see any difference, but if
> you look again after one day you see if the wristwatch is then off by
> one second, or by 2.
>
> However, this works only well if your wristwatch drifts at the same rate
> all the time. This may have been the case with old mainframe servers
> which had good oscillators onboard, but normal PCs usually have cheap
> xtals only.
>
> The frequency of these xtals usually changes significantly due to
> changes in the ambient temperature, and the temperature inside and
> outside the PC housing can change frequently, when the air condition
> kicks in or out, when the CPU changes from idling to high load, etc.
>
> So if the frequency changes during long poll intervals then there's no
> increased accuracy, and my observations show that the system time is
> adjusted smoother if the polling interval is kept low.
>
> Martin
0
William
11/17/2016 4:17:29 PM
On 17/11/16 16:17, William Unruh wrote:

>
> Measurements I made show that the clock rate fluctuates during the day,
> because the computers work harder during the day. One of the reasons
> that chrony does so much better than ntpd in keeping the offset low is
> its much faster ( and very non-linear response) to those sorts of
> non-gaussian noise.

Huff-n-puff was introduced because of a real world problem which 
resulted from ntpd being too good at keeping the "offset" low.  If 
chrony is even better, it will perform even worse than ntpd in the 
situations for which huff-n-puff was introduced.

The problem is that of, particularly workstations, making large 
downloads at certain times of day.  In the early days, of dial up lines, 
the round trip time would go so high that the polls were rejected for 
excessive delay.  However, when connections got faster, a large, 
asymmetric, delay was introduced which wasn't large enough to reject the 
responses.  As ntpd assumed a symmetric delay, ntpd saw a large offset, 
which it tried to correct.  huff-n-puff, attempts to estimate the 
asymmetry and compensate for it.

Although connections have got faster, buffer bloat may well mean that 
the the absolute size of the asymmetry hasn't reduced in proportion.

It is important to understand that what one wants out of a time 
discipline is to reduce the offset from the ultimate reference clock, 
but the ntpd "offset" metric doesn't measure that, and in the cases 
where huff-n-puff is useful, it can falsely indicate a large correction 
is required, when the correct thing is to ignore it.
0
David
11/17/2016 7:15:09 PM
On 2016-11-17, David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 17/11/16 16:17, William Unruh wrote:
>
>>
>> Measurements I made show that the clock rate fluctuates during the day,
>> because the computers work harder during the day. One of the reasons
>> that chrony does so much better than ntpd in keeping the offset low is
>> its much faster ( and very non-linear response) to those sorts of
>> non-gaussian noise.
>
> Huff-n-puff was introduced because of a real world problem which 
> resulted from ntpd being too good at keeping the "offset" low.  If 
> chrony is even better, it will perform even worse than ntpd in the 
> situations for which huff-n-puff was introduced.

If chrony accepted such offsets, yes, that would be bad. But it has a
filter which is supposed to drop such samples. When a link is saturated
with download or upload, it will coast through. The ntpd's solution for
buffer bloat is to adjust the offset assuming the extra delay is all in
one direction (which may or may not be true) and chrony's solution is to
ignore such samples. This works well as long as the estimated stability
of the clock can hold over the whole interval in which the measurements are
unusable. In my experience, buffer bloat persisting for a couple hours
is not a problem.

-- 
Miroslav Lichvar
0
Miroslav
11/18/2016 8:54:30 AM
Miroslav Lichvar wrote:
> On 2016-11-17, David Woolley <david@ex.djwhome.demon.invalid> wrote:
>> On 17/11/16 16:17, William Unruh wrote:
>>
>>>
>>> Measurements I made show that the clock rate fluctuates during the day,
>>> because the computers work harder during the day. One of the reasons
>>> that chrony does so much better than ntpd in keeping the offset low is
>>> its much faster ( and very non-linear response) to those sorts of
>>> non-gaussian noise.
>>
>> Huff-n-puff was introduced because of a real world problem which
>> resulted from ntpd being too good at keeping the "offset" low.  If
>> chrony is even better, it will perform even worse than ntpd in the
>> situations for which huff-n-puff was introduced.
>
> If chrony accepted such offsets, yes, that would be bad. But it has a
> filter which is supposed to drop such samples. When a link is saturated
> with download or upload, it will coast through. The ntpd's solution for
> buffer bloat is to adjust the offset assuming the extra delay is all in
> one direction (which may or may not be true) and chrony's solution is to
> ignore such samples. This works well as long as the estimated stability
> of the clock can hold over the whole interval in which the measurements are
> unusable. In my experience, buffer bloat persisting for a couple hours
> is not a problem.
>

The key here is that you can still get some real information from a 
severely (one-way) lagged connection: As long as the measured offset is 
less than the above-baseline RTT then this sample can be explained by 
bufferbloat, but when that stops being true you know that the local 
clock must be adjusted.

You don't know exactly how much is the correct adjustment, but it has to 
be enough so as to keep the local clock within the cone of uncertainty.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
0
Terje
11/18/2016 9:20:23 AM
On 2016-11-18, Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> The key here is that you can still get some real information from a 
> severely (one-way) lagged connection: As long as the measured offset is 
> less than the above-baseline RTT then this sample can be explained by 
> bufferbloat, but when that stops being true you know that the local 
> clock must be adjusted.

Right, but the "one-way" part is pretty important here. Generally, you
don't know if it's one-way or not. If it's not, the adjusted offset will
actually make things worse and that's why the huff-n-puff filter
shouldn't be enabled by default.

-- 
Miroslav Lichvar
0
Miroslav
11/18/2016 10:22:25 AM
Reply: