-g screqup (from IRC)

[Hal Murray]

gem at 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.