On 2011-09-21, Harlan Stenn <[email protected]> wrote: > Bill wrote: >> On 2011-09-21, Harlan Stenn <[email protected]> wrote: >> > Bill wrote: >> >> Some operating systems (eg Linux) have the ability to do a much faster >> >> than 500PPM rate change (100000PPM in the case of Linux) but ntp does >> >> not make use of that. >> > >> > ... because it would violate the assumptions and rules about the loop >> > behavior (I'm painting with a wide brush here). If you want a system >> >> ? But that 500PPM was an arbitrary and random value chosed X years ago. > > "Arbitrary and random" sounds like Spin to me. > > It was several sigmas bigger than the expected worst-case "acceptable" > clock drift.
And it could have been 1000 PPM or 2000 AFAIK, and it would not have made any difference. > > What are the effects of a different (presumably larger) value going to > have on the behavior of the loop? Why should it have any effect? steps do not appear to have any effect. > > What will the effect be on other systems that "associate" with these > boxes that have the faster rate? > >> > that is designed to work with a faster slew rate that's fine, but then >> > you also have to consider legacy and interoperability issues. >> >> sure. But what legacy issues do you have in mind? > > machines that operate at the 500ppm limit that are now talking to > machines that operate at this new higher rate. Clearly if the machine is at the end of the chain, it should not matter. If it operates as a server, the 500PPM system will fall behind until the rate drops and then will catch up. Or it will have an offset greater than .128ms and step. > > Applications that "knew" that if a time correction was going to happen, > it would be at the 500ppm rate - this goes to data correlation and > timestamp sequencing. But ntpd is allowed to step, so it has to assume that an infinte rate is possible. > > That's just 2 legacy issues off the top of my head. > >> > It also goes to timestamp correlation issues. >> >> It would seem to me that a step (infinite PPM) would be far far worse. >> ntpd does NOT limit the slew rate to 500PPM. It limits it to infinite >> PPM. > > And when it does it logs the event, so it is still traceable and > auditable. It's also an indication of "something is wrong, as this > should not have happened." But your questions where what happens to other systems. a drift of 500PPM for an hour is surely just as bad. > > H _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
