On 2010-07-26, Thierry MARTIN <thierry-mar...@ifrance.com> wrote: > On 26 juil, 16:39, unruh <un...@wormhole.physics.ubc.ca> wrote: >> On 2010-07-26, Thierry MARTIN <thierry-mar...@ifrance.com> wrote: >> >> > Hello, >> >> > Is there any API that can be used in a program to be "notified" if a >> > "step time server" event occurs? >> > As far as I could see, it is "only" logged. >> >> You could have something read the logs and notify your program. Or if >> you are on Linux/BSD you could run chrony, which does not step. >> Mind you if ntpd is stepping after having been running for a few hours, >> something is seriously wrong, and needs fixing. >> >> >> >> > Thanks in advance for your answers. >> > / Thierry > > Unfortunately, watching the logs does not fit my need. > I will try and explain what are my constraints. > > My program is doing network packet acquisition on several links and > needs to sort them - based on the timestamps. > Also, many network measurements are very badly affected by time > stepping forward or backward. > > This explains why I'd like to be notified of time steps. (It is easy > when time is going backward, but not in the other case). > > I think ntpd ajusts time by step if the system looses connection to > ntp sources for a while (I set up the step threshold to 1s on the ntp > server).
No. ntpd steps if the time is out xby more than 125ms. This is a failure of ntpd, but it is NOT something that should happen. Your clocks should not step even if they loose connectivity for a fair while if their frequency has been disciplined-- and if your network looses connectivity, then your network monitoring is screwed anyway. You might also want to let the clock freewheel (ie do not use ntp to discipline it) but use ntp to find out how far out your clocks actually are. Then again you can use that info to correct the times of the timestamps after the fact. But this stepping is simply a feature of ntpd. If you do not like it, use chrony instead (unless you are on windows). By looking at the logs, you can at least post facto resort your network timestamps > > Anyway, thanks for your help. > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
