"David L. Mills" <[EMAIL PROTECTED]> writes: >David,
>The original model implemented in the Alpha kernel does not step the >clock backward unless the step is greater than two seconds. Rather, it >stops the clock and advances one microsecond at each read. This applies >whether NTP slews or steps. Various ports of that code have broken this >model in every possible way. >The 500-PPM slew once was common in the ubiquitous Unix kernel. The >value was chosen as a compromise between short slew time for relatively >small adjustments and moderate resolution during the slew interval. This >works out to 5 microseconds per tick with a 100-Hz clock and a 5-us >jitter. In truth this could be changed to anything you want, as long as >the value is fixed. OK, so there was no magic in that 500PPM limit. Is there a difference between the tick size adjustment and the frequency adjustment (CPU-counter-to-time conversion factor). >Some kernelmongers, including SGI and Linux, have put up fancy code >designed to reduce the slew time for large adjustments. This inserts and >additional pole in the clock discipline impulse response which results >in unstable behavior for adjustments over half a second or so. That is of course not good. I am a bit uncertain why that instability would depend on amplitude. Is the response a non-linear response? For linear responses the amplitude should not matter. But from your words it sounds like the reponse is amplitude dependent which would of course be non-linear. And if it is non-linear, once it gets near (1 sec?) the right time, that linear stable response should take over. By the way, do you happen to know how the Linux kernel inpliments the adjtime system call (adjtimex ADJ_OFFSET_SINGLESHOT) does its slewing? >The default step threshold is 128 ms; the -x command line option sets it >to 600 s and does nothing else. The 600-s value was chosen as the >expected accuracy with eyeball and wristwatch. If the extra pole is not >there, the original response is preserved over that range and largely >independent of the slew value itself. >Say you change from 5 us per tick to 1 ms per tick or 100 ms/s. This >would amortize a 600-s adjustment in almost two hours and reduce the >resolution to 1 ms. If your extended network requires synchronization to >better than one second, in all but the last second of that slew the >network would not be synchronized. This paragraph confuses me. If the clock is 600s out, it is way out no matter how you slew it back. What do you mean "reduce the resolution to 1ms"? The resolution is still 1usec and the accuracy is a few hundreds of seconds. And if the clock is out by 600s the network will not be synchronised to true time. Or perhaps you mean something else than that with "network would not be synchronized". Thanks >Dave >David Woolley wrote: >> Unruh wrote: >> >>> >>> Not at 500PPM limit but if you use the tick adjustment, it is more than >>> enough time. (The tick adjust limits out at 100,000PPM) >>> >> I believe ntpd assumes that it is constant. Having a large tickadj >> causes poor resolution when using the user space discipline. >> >> I suspect that Dr Mills would say that a high slew rate also compromises >> the system behaviour when you cascasde multiple strata. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
