"Danny Mayer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Maarten Wiltink wrote:
<leap second adventures> > Maarten, I'm not sure why you would do this. First of all step-tickers > is a Red-hat thing for using ntpdate before starting ntpd. You are far > better off just starting ntpd with the -g option and iburst on the > server lines. All this messing with the drift file doesn't really help > you. You should let ntpd do its job and set the drift value. Step-tickers is a Redhat-ism, yes. I'm aware of that. These are Red Hat boxes. The init scripts are there, I know how they work, I'm not about to change them. In this case, it was a _convenience_ that I could disable initial stepping by renaming a file in the /etc/ntp directory, without touching my init scripts. (I may yet make a small adjustment there. The script checks for the existence, rather than the readability, of the file. I would have preferred to revoke read rights instead of renaming the file.) The iburst is there. Adding it clearly and obviously made things better. The -g option isn't. Frankly, I don't care much for all the flap about deprecating ntpdate. Given that I have something that I know, and that works, how exactly, objectively, would I be better off? Please try to think of arguments that convince _me_, not just you. If you say messing with the drift file didn't help me, perhaps you'd care to read again what I wrote. I let ntpd do its job for twelve hours, but its upstream servers disagreed, ntpd hopped between them like crazy, stepped back and forth, _stepped halfway_ half the time, and ran itself onto the 500 PPM limit several times. So I told it to stop doing all that (disable ntp), and after a false start fed it a drift value that got it near actual time after another few hours. Instant end to chaos. No step was necessary when re-enabling ntp. I fail to see how this did not really help me. I have five nodes running off that server; I think not stepping is a good thing. If you will take my word for it that ntpd was turning garbage in (four _severely_ disagreeing servers) into garbage out (symptoms as described above), could you suggest a better plan than coasting with manual corrections? By the way, coasting with manual corrections is as close to a hardware clock as I'll consider. I'm not a soldering type of guy, and I'm not spending eighty dollars on it, either. Groetjes, Maarten Wiltink _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
