David Woolley wrote: > Martin Burnicki wrote: > >> >> This is not quite correct. Even older versions of the NTP port for >> Windows >> have tried to interpolate the timer ticks using the performance counter. >> > I *was* aware of that, but that doesn't change the fact that ordinary > applications only see the time updating on a tick; only ntpd benefits > from the interpolation. On modern Unices, all applications get high > resolution clock readings. > > Also, I believe that the zero point of the interpolation is rather > sensitive to scheduling delays on loaded systems.
If you think about it, you'll realize that the NTP sw clock, based on RDTSC or other high-res timer not locked to the OS clock, is another FLL/PLL. I.e. to do it right you cannot simply extrapolate from the last timer tick, you should instead weigh those TSC samples that have the least latency behind the actual timer tick. The real problem is that you can very easily end up with two sw locked loops on top of each other, and from what little I remember from my Uni control theory classes, this is an easy way to destroy stability, unless at least one of those loops are very simple. Terje -- - <[EMAIL PROTECTED]> "almost all programming can be viewed as an exercise in caching" _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
