In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > No attribution wrote:
[ This is a repost because the original incorrectly referred to exponential averages. It supercedes the original, which may work on usenet servers, but not on the mailing list. ] > I've implemented code to emulate what adjtime does with respect to > slewing the clock. I have a 64-bit nanoseconds counter based off the When you are working at this level of accuracy you probably need to implement the equivalent of the kernel PLL used with some implementations of ntpd, not the simple adjtime processing. That is you implement the feedback algorithm incrementally on every tick. > processor cycle counter and I use a 60 Hz clock interrupt to increment You need very predictable interrupt latency. On many desk top systems the uncertainty due to latency is over 1ms. Interrupt latency is also important for what you are measuring. That's likely to be even larger on a general purpose system. > > All bets are off it you have no external source since it has no > > source of information to compare it to in order to make calculations. There is a stock response here. Whilst it is true that you are not running a conformant NTP unless you have a source of true time in the system, in terms of tracking the oscillator on another machine, the worst case is only twice the maximum frequency error to compensate, and, in practice, the errors will tend to track, meaning that there is less frequency error to correct to maintain phase (although the phase will wander relative to true time) - the difference between two devices drifting in similar ways will tend to be less than between a non-drifting source and just one of them. > > Do you have a refclock? You should consider getting on for this > > server as it will do a much better job of giving you accurate time. A lot of these mis-uses of NTP don't need accurate time, only that some arbitrary monotonic function of time with a slope close to 1 is matched across all the machines. They don't need much long term accuracy. > Any pointers to code or documents describing how to estimate clock skew The NTP source code is open. > and/or reduce the effects of jitter would be great. I've read the SNTP > 4 spec (no NTP 4 spec that I could find), but it doesn't really discuss > it. The lack of an NTP 4 RFC is a sore point. The NTP RFCs page, off the main NTP site, says there is no public document, although there have been claims that there is a public draft (the problem is that, for reasons which I think are good but Dave Mills thinks are bad, RFCs have to be in a low technology (and therefore long lasting) format). There are, however, some presentation slides which seem to document nearly everything. However, if you are constrained to integer arithmetic, you probably want NTP V3, for which there is an RFC. One of the big changes in V4 was moving to floating point on the grounds that it was no longer a problem and the only way to get really good accuracy. > I can do normal math to extrapolate a slope given the clock offsets and > use that to predictively slew time, but I was hoping there were better That sounds like the statistician's approach, as championed by Nick McClaren. NTP uses a control engineering approach, based on the technology that would be used with analogue electronics. Basically this uses the measured error to control the rate of change of time and frequency correction. In the analogue form it is called a phase locked loop and is a common circuit in nearly all modern radio equipment. The feedback loop is basically a couple of linear infinite impulse response filters low pass filtering the phase and frequency error, however there is a pre-filter that tries to select the sample with the lowest uncertainty, and the parameters of the linear filters are modified as the loop converges in an attempt to balance the effects of jitter and frequency instabilty, whilst giving a fast initial convergence for a this simple type of feedback system. Jitter effects are minimised by only partially correcting on any one sample, thus averaging the jitter, and by adjusting the polling interval to try and balance the errors from jitter and frequency drift. > NTP ways of doing things. A non-floating point algorithm would also be > desirable. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
