On Feb 9, 2012, at 4:05 PM, Chris Albertson wrote: >> Exactly. If the server reports a time that is further than the panic >> threshold from the client's clock (which defaults to 1000 seconds) then it >> will reject the server and exit. A human is then expected to manually >> inspect the situation and set the clock to something reasonably close. The >> -g flag lets you disable this sanity check. > > I think what you describe applies to the case where a client NTP > starts up and notice the time is very far "off". But I think (??) > the question was that the client is in sync and then the server's time > jumps. I thought -g only applied to start up logic. I could be > wrong. This situation would never happen on a properly configured > network.
Ah, yes, my response was in the context of client starting up when there is a single server, and it is very far off from what the client believes is the current time. From what I recall in earlier testing, if ntpd is running and synched, and the remote side does something crazy like a multi-year jump, then it is promptly marked and ignored as a falseticker. I'm not sure that I've ever tried doing this with just a single server specified, though. I think that -x specifies the max deviation allowed when doing a step via settimeofday() rather than slewing the clock with adjtime(), and it is limited to a max permissible jump of 600 seconds, except for possibly a one-time "big" jump at startup allowed by -g. Regards, -- -Chuck _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
