On 2015-02-12, Philip Homburg <[email protected]> wrote: > In article <[email protected]>, > brian utterback <[email protected]> wrote: >>Dr. Mills crafted a wonderful piece of software, amazing for its time, >>but he no longer actively engages us much at all. I understand, that >>isn't his fault. But no one who does actively engage really understands >>it or knows how to improve it. Unruh has a point, we don't know if there >>isn't a better way built on statistical analysis. Perhaps a hybrid >>between the two approaches would be better still. But we don't even know >>the consequences of changing a single constant with any degree of >>certainty. > > Some time during the mid 90s, I created a new type of control loop and wrote > an NTP implementation that uses it. In testing I verified that it is stable at > slew rates of 100000 ppm. No need to go beyond that. > > But I have no way of proving that it is correct. At the time I felt it would > take too much energy to convince Dave Mills to adopt it, and I didn't want to > promote a competing NTP implementation either. So I'm just running it for > my own ammusement. > > If people feel a strong need to go beyond what NTP does (and are willing to > write the specs, code, etc.) then I can try to dig out what I still have > in this area.
chrony already does this on Linux. It uses both the fine slew and the tickadj on adjtimex to enable slew rate up to 100000 ppm, the limit of the tickadj. The complaint of the ntpd people is not the stability of the machine itself, but the stability of the network, where for example A could use B and B use A in determining its own time. Is the whole network stable under this kind of loop. And what happens to B when A suddenly begins to slew at 2000PPM? Note the "suddenly". Rarely is it the case that the drift rate of A will suddenly change by 500PPM. But that A's clock could be stably out by 500PPM IS possible. ntpd does not differentiate between those cases. Also ntpd has to concern itself with cases in this it is not the kernel that adjusts the drift, but ntp itself with its own "once per second" internal slewing. That this takes place only once per second adds in an additional problem. chrony does not have its own internal slew. It only uses the kernel (adjtimex) to alter the clock rate. > > _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
