Maarten Wiltink wrote:
> "Danny Mayer" <mayer@xxxxxxxxxxx> wrote in message
>>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.
As I commented to Tom some time ago, trying to obsolete ntpdate is a bit
like obsoleting nslookup, it may never actually happen. So I'm not going
to try convincing 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.
I was bothered about the tinkering with the drift value as I was not
convinced that you were doing anything helpful. If the servers you were
using were badly off, for some meaning of off, then perhaps the best
solution would be to choose new servers, at least for the time being.
> 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.
Well yes. If ntpd is receiving garbage it can choose to do one of two
things: 1) ignore all and not discipline the clock, for which it has to
decide that it's not receiving anything useful with which it could make
a decision; or 2) take what it's given and churn out garbage as you
said. My suggested solution is to point to different servers and see if
things get better.
> Maarten Wiltink
questions mailing list