[ntp:questions] Tighter regulation?
Mischanko, Edward T
Edward.Mischanko at arcelormittal.com
Sat May 25 09:55:26 UTC 2013
> >>> On 2013-05-21, Mischanko, Edward T
> <Edward.Mischanko at arcelormittal.com>
> >> wrote:
> >>>> My concern is that too much data is being thrown away when polling
> >>>> above 256 seconds and that allows excessive wandering of my clock.
> >> If too much data is being thrown away, it would be because the poll
> >> adjust algorithm has chosen too high a poll interval (or you have too
> >> high a minpoll) for the noise statistics.
> > [Mischanko, Edward T]
> >
> > This is exactly what I am saying!! This needs to be corrected; I
> consider it a bug.
>
[Mischanko, Edward T]
I would modify the current algorithm with an exception that if offsets
exceed 1 millisecond for more than one polling cycle, then, polling will be
reduced by one interval, else, continue normal operation.
> How would you modify the algorithm that chooses the poll interval.
> Remember that getting too low a poll interval will make ntpd track short
> term variations in network latency and prevent it getting an accurate
> estimate of the crystal frequency error.
>
> Please provide a detailed specification of your proposed algorithm.
>
> > Too much assumption is made that everyone will have the perfect computer
> and
> > the perfect network when configuring these various filters. What works
> on
>
> A lot of allowances have been made for the real world. The only
> allowance that has not been made is that it assumes that crystal
> frequency errors are essentially random, and thus can get into
> difficulty if a (normally very cheap) motherboard crystal is in a
> thermal environment that exhibits non-gaussian behaviour.
>
> > the blackboard does not always work in reality. My computer has a
> > -19 precision but it can't keep time inside 1 millisecond with default
> > Settings; go figure.
>
[Mischanko, Edward T]
Yes, there are many things that I do not understand about the various
latencies, and the difficulties of interpolating clock ticks, and writing
software code. I do know that as great as NTPD is, it doesn't work as well
as I thought the authors intended on my system. I seek improvement and not
to berate anyone.
> I figure that you don't understand the various latencies that exists in
> the system and network, and the difficulties of interpolating clock
> ticks on Windows. The precision figure, for Windows, is almost
> certainly optimistic because of the hacks ntpd has to go through to
> interpolate the clock in user space.
>
> The reason for the difficulty in interpolating is that Windows does not
> achieve anything like the timing resolution in the Windows API
> architecture. Earlier versions of Windows NT could only supply time to
> applications to a resolution of 16ms (before ntpd started doing user
> space interpolation, NT 3.5 would return an ntpd precision of -6).
> Intermediate ones had a variable resolution, depending on the use of
> multi-media timers, but I don't think it was better than 1ms. I'm not
> sure of the exact parameters to the latest generation; but I don't think
> ordinary applications will be seeing anything close to 2 microsecond
> resolution. (Changes of multimedia timer rates, causes upsets.)
> Basically, you may find that the main error component in the time
> supplied to ordiary Windows applications is due to the limitations of
> the Windows time reading APIs.
>
[Mischanko, Edward T]
It is an offset from the best time source I have available. How high of an
offset is intended to be acceptable?
> Also, I don't remember your ever describing a test rig that is capable
> of comparing the system time on your servers to true time. Offset is
> not offset from true time. Without special instrumentation, or an
> accurate theoretical model, you cannot assume that high NTP offsets
> represent errors in the machine time keeping.
> >
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
More information about the questions
mailing list