> >>> On 2013-05-21, Mischanko, Edward T
> <edward.mischa...@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@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to