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. The bug was seen on a
stable corporate LAN, of which I am now locked out of by the IT
Security Gestapo.
Huh, what have you done? ;-)
I am no longer able to use your stable, or test your
developmental software at my workplace. I also am no longer able to
provide constructive feedback on this software in this environment.
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.
Martin
I had maxpoll set at 10 when I first setup my network but sometimes
at that poll rate combined with daily temperature variations offsets
would gradually increase both in +ve and -ve directions. This could
clearly be seen in mrtg graphs. Solution was to reduce maxpoll to 7
or 8. I never thought of this as a bug. There was a daily variation
depending on season and a variation due to system load.
This has been with NetBSD 1997 to date and a period of a few years
when running FreeBSD. Currently NetBSD-6, ntp-dev-4.2.7p401, four
of the servers are in the pool.
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
