On 2015-02-13, Harlan Stenn <[email protected]> wrote: > William Unruh writes: >> On 2015-02-12, Harlan Stenn <[email protected]> wrote:
> > It would have been far better for folks with those broken kernels to > have simply removed any drift file before starting ntpd. The code to > remove the drift file could have been removed once the problem got > fixed. Of course. But the thing about computers is that they can take over and reliably do what people could do with much additional work, and if it has to be done after time, can remember to do each time. Is ntpd a place where it could take place? Yes. And the other problem is that even if they removed the drift file, they could be screwed by the 500PPM limit. If their kernel that time happened to be out by 470PPM, that would have left only 30PPM for ntpd to work with. > > Or folks could have proceeded with an idea I had years ago - write the > tick value (or the frequency) to the drift file, and when starting up > make sure those values were still appropriate. I never have understood how they calibrated the system clock in the first place. What acts as the reference? The rtc? > > But again, how far should we go to accomodate braindamage? One could say the same for stupid networks, but ntpd spends vast amounts of time and comprimizes to deal with very rare network problems. > > Ntimed is beautiful and small. And every time somebody decides to > address some new issue, the code will get bigger. Yes, that is a problem with dealing with the real world. > >> > - that should have been predicted and accommodated by stable-running >> > software and algorithms that have been around for decades, >> >> That the kernel people screwed up was perhaps unpredictable. That clocks >> could have drift rates substantiallydifferent from 1 sec/sec could have >> been predicted. >> >> > >> > - where no other kernel has ever misbehaved in this way, >> > >> > - and other projects should deal with that mess; >> > >> > - and chrony, a program with one design goal of closely tracking a >> > master avoids this kernel brokenness. >> >> All of the above are predicated on you wrong assumption that I thought >> that the kernel screwup could be predicted. > > I don't see it that way. > > The linux folks went ahead and did something Unusual expecting other > folks to deal with their mess. No. I doubt very strongly that they did it on purpose. They screwed up and then did not know how to fix it was how I saw it. If you have evidence that it was malice rather than incompetence, I would love to hear of it. > > Kinda like when they took the PPASPI and decided that they were not > going to implement both MOD_ and STA_ bits because they were "similar" > and then got huffy because they changed something they were not using > and the folks who were using it didn't feel like cleaning up that > externally-created mess, either. No idea of that. > >> > And the net effect of the above indicates a shortcoming in the way NTP >> > was designed, right? >> >> The inability to deal with the real world, when that is one of its >> design goals IS a shortcoming in NTP, yes. > > Bullshit. > > How about "the unwillingness to deal with excessive stupidity"? Unfortunately excessive stupidity is an attribute of the real world. And the fix is NOT difficult for something like ntp to handle. > >> > That's OK, and it's why I don't take your messages very seriously. >> >> Of course I cannot make you take anything seriously. I would have >> thought that designing ntpd to handle the real world would be something >> you take seriously. And that when you discover a feature of the real >> world that ntpd does not handle but could, that you would seriously >> consider changing ntpd so that it does. > > Some behaviors are so broken it doesn't make sense to try and accomodate > them. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
