Guys, I haven't read every word on this thread, but all I can contribute is that nothing reported here is anything like my experience here. Our servers pogo.udel.edu and rackety.udel.edu are synchronized via GPS and PPS. I invite the skeptics to peek at them from time to time. I describe their behavior as like cats; most of the time they are quiet and gentle at a few microseconds, but once in a whild they show a surge of ten microseconds or more, especially after a power failure, which we do get from time to time.
There is a persistent report that appears as a low-frequency ringing with more or less constant period. This would seem to suggest something wrong with the discipline loop transient response. In the past the most likely cause has been an ill-advised tinker with the Unix adjtime() system call with the dubious purpose of reducing the time to slew the clock over some range. This wrecks the transient response and easily leads to loop instability. If you are using the kernel time discipline and not adjtime() this is not an issue. There are lots of ways to measure the loop transient response. The easiest way is to set the clock some 50-100 ms off from some stable source (not necessarily accurate) and watch the loop converge. The response should cross zero in about 3000 s and overshoot about 6 percent and smoothly amortize over several hours. Be sure to clamp the poll interval to 64 s over that period. If it does something else, like show an exponentially decreasing ringing. Go looking for trouble. As for "offset should be much larger than the error", be careful here. By error I assume you mean what ntpq rv shows as jitter. The best case is when offset is indeed less than jitter; if the error is much larger than error, this suggests the frequency has surged and the time constant/poll interval needs to be reduced. Watch the poll interval behavior in the loopstats data. Dave David Woolley wrote: > In article <[EMAIL PROTECTED]>, > Unruh <[EMAIL PROTECTED]> wrote: > > >>No, the offset is the value reported in loopstats. > > > Same thing. If chrony is reporting the same measurements, neither set of > measurements is particularly valid. You need to measure the actual > offsets, using something that has a repeatability a couple of orders > of magnitude better. Certainly for ntpd, offset should be much larger > than the error, when locked. Is the server running ntpd? > > Anyway, as I said, arguing by proxy is difficult and I'm rather hoping that > Dave Mills will take over. Certainly it is Dave Mills you have to > convince if ntpd is going to change. > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
