g...@rellim.com said:
>> logconfig =syncall +clockall +peerall +sysall
> sysall not in the ntp.conf man page. I also do not see anything related to
> allow_panic that would log when the options is taken: ntp_loopfilter.c
The logging stuff goes through a subroutine, one for each of the 4 types.
That subroutine translates a compile time constant to a string, maybe logs
it, and maybe saves the new state. I'd have to check the code to be sure.
If you grep for clock_step, you will find the translation table.
./libntp/statestr.c: { EVNT_CLOCKRESET, "clock_step" },
If you grep for EVNT_CLOCKRESET you will find the place in ntp_loopfilter
where it gets used.
> I got the test case, as in my previous email:
> # killall ntpd; sleep 1; ntpd -N -g
That test case doesn't show that -g is the problem. I expect you would get
the same thing without the -g.
> But so many bad things going on there hard to tell one from the other.
Then why are you claiming that -g is causing the problems? That's why I said
"wild goose chase".
Please start a new thread with a description of the start/restart quirks you
are seeing and the environment. Graphs and/or test cases are good.
> OK, then we can call this case the "stop/start' or 'restart' case. Fair
> enough?
I'd be happy with either. If you say restart, I will probably assume you did
something like "service ntpd restart".
> I find a minimum test is at least 24 hours, better yet 48 or more.
That doesn't match my experience, at least if you are talking about
start/restart transients. After a while the normal temperature fluctuations
and such will dominate any initial conditions. I'd guess "a while" is closer
to an hour or 2 rather than 24 or 48. If you have a clean signal, the
exponential decay of the time offset might still be visible for 6 hours. I
haven't looked carefully.
--
These are my opinions. I hate spam.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
