On 2013-12-02 05:02, Martin Burnicki wrote:
Ed,
Mischanko, Edward T wrote:
Martin,
Reading your reply, it sounds like you understand and somewhat
confirm this bug.
I *think* I have observed something like this some time ago.
I agree this may be a Windows XP only bug.
I'm not sure whether it is. We'll have to find this out, but this can be very
time-consuming.
We need to test both ntpd-stable (4.2.6p5) and ntpd-dev (4.2.7p???) both under
Windows XP and Windows 7.
Under Win XP both ntpd-stable and ntpd-dev should converge fine at low polling
intervals. We need to know if one of them or both are still stable when the
polling interval increases beyond 7.
Under Win 7 ntpd-dev should also converge fine at low polling intervals, so
another test could find out if it also stops to converge when the polling
interval ramps up beyond 7.
ntp-staple might converge under Win 7, or not. If it doesn't at low polling
intervals then it makes no sense to see what happens if the polling interval
ramps up, if that happens at all.
Since this seems to happen under Windows only, the reason could be some
calculation error or overflow, and it can have been unintentionally fixed or
introduced between ntp-stable and ntp-dev.
So IMO we first need to find under which conditions this occurs, then we can
try to find a bug in the source code.
I have not the ability to confirm this bug on newer versions of
Windows or newer versions of NTP at work.
At home, I found all the FreeBSD and Windows, XP and 7, ports to be
unstable in the WAN / Internet environment.
Hm, if even the FreeBSD version is unstable I'd say this is due to you network
environment or configuration.
As said above, a reliable test should first make sure that proper
synchronization is possible, i.e. with a stable network connection and a good
upstream NTP server.
NTP polling increases
regardless of offset and NTP appears not to keep up or sync the
clock. I have not observed any over-regulation that is feared with a
shorter polling interval. My primary goal is to have the smallest
offset as possible; after that goal is met, I can worry about clock
jitter. Is that the goal of NTP? If so, it is not working in the
100% network environment, with no PPS reference server use, and
default software settings.
I would be happy to answer specific questions if my observations are
still not fully understood.
I've just set up some tests with XP/ntp-stable and Win7/ntp-dev to see how it
gores and if I can confirm this bug.
When I ran current stable under Win 7 with only network servers I found
I had to drop minpoll to 4 (default is 6) so iburst would quickly get
a good offset and pull drift down from initial out-to-lunch estimate
compared to drift file contents.
Once drift got pulled down close to hardware levels, poll would increase
and further pull down offset < 10ms, then at longer poll intervals,
both drift and offset would slowly get more accurate over a period of
about three weeks.
About then patch Tuesday would come around and it would be back to square one!
I had to ensure BIOS spread spectrum and OS power saving were turned off
and pick servers that were not busy, with no drops or steps, delay < 90ms,
jitter < 20ms, offset < 10ms.
As pings were often blocked, I used traceroute (tracert on Windows) to do
initial delay estimates, when those were not also blocked in a DMZ, and
tried ntpq -p -c rv -c cv as a final check out when possible.
I try to pick about four good quality servers which may be quite distant,
but within the criteria above, and four decent fairly local servers for
those times when interconnects fail and only local servers are reachable.
One thing I have noticed is that my NTP clock (HPET) is being reported
as having ~28PPM drift where my hardware is only ~.9PPM!
--
Take care. Thanks, Brian Inglis
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
