On Fri, Feb 10, 2012 at 00:16, Chuck Swiger <[email protected]> wrote: > On Feb 9, 2012, at 4:05 PM, Chris Albertson wrote: >> 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.
Close but no cigar -- -g allows a single step exceeding the panic threshold, not necessarily at startup. So if the client didn't need to step more than the panic threshold at startup, a single subsequent panic-exceeding step is allowed. A second such incident would then cause the client ntpd to exit. > 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. -x is equivalent to "tinker step 600", as explained in http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html This changes the step threshold from 0.128 to 600, and as noted in http://www.eecis.udel.edu/~mills/ntp/html/miscopt.html#tinker any step threshold greater than 0.500 disables the kernel clock discipline loop (as does "disable kernel"). Let me RTFM that for you, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
