[ntp:questions] Best ways to get the reference times from ntp

mike cook michael.cook at sfr.fr
Wed Apr 30 13:51:05 UTC 2014

Le 30 avr. 2014 à 14:05, Maximilian Brehm a écrit :

> From: Rob <nomail at example.com>
>> Maximilian Brehm <maximilian.brehm at tu-ilmenau.de> wrote:
>>> This is related to another questions by me a few weeks ago. I wrote a
>>> reference clock driver that uses a clock that only provides timestamps
>>> relative to its starting point. It works well when setting its offset to
>>> the system clock via CLOCK_REALTIME and clock_gettime to stabilize the
>>> system clock. I would now like to include external ntp server. I can not
>>> be sure that the system time is within millisecond range of the
>>> reference time.
>>> As far as I understood the ntp algorithms (especially
>>> the select phase), if I continue to set the offset relative to the
>>> system time my clock would be identified as false ticker at least in the
>>> early phase of the algorithm. >> >> Regards >> >> >> Maximilian
>>> Brehm
>> I think it is similar to the problem faced by gpsd and the ATOM
>> reference clock.  The trick in those clocks is to use a "gate" that
>> enables the clock only after ntpd has synchronized with another
>> clock on the network that provides absolute time.
>> But in the above case, the problem is only that PPS provides information
>> about the time a second starts, but no numbering of the seconds.
>> So you only need to bring the clock within a few hundred ms of the
>> correct time, then enable the "gate" of the PPS refclock and the clock
>> will finetune to the PPS clock.
> But how to detect whether the time was set correctly (in or out of the
> application)? Or how do I get the absolute timestamps of the various
> peers?
  The time_t stamps are available as the transmit time in all ntp packets coming from the peer. One way you could get them is to run ntpdate -d against the peers. You could do that in your program in a pipe and parse the stdout. 

   I am still confused as to the current status. 
   If I am following ,you are collecting timestamps (which are offsets from the moment of boot of a remote system) and with which you are populating shared memory attached to the shared memory refclock driver. At the moment these are absolute offsets (say with a base of 0 , or 00h00m00s 1 jan 1970 in the unix epoch), and you are saying that your system clock is synchronizing correctly by NTP with reference to that epoch . So your system should be now showing dates well in the past. 
Is that the case?  
Now you want to add a network ntp server to the config to get your system clock UTC sync'd. If that is the case, before starting NTP normally,  you can set the system clock to that of a bunch of servers with either ntpdate, or ntpd -g. If you have no network at this point you will be able to detect it and take further action such as requesting that the date be set manually. That will give you a reasonable starting value sync'd to UTC. Then you can "normalize" your refclock  timestamps by computing the offset with the now correct system clock value and adding that fixed delta to each of the new raw timestamps before populating the shared memory. 
  Is that the plan? Or have I lost my paddle. 

> I misused terminology. I did not write a reference clock driver in NTP
> but an external application that uses the shared memory reference clock
> driver. It does not provide a PPS signal currently and to provide it is
> a hack (since it is not a device but an application that reads the
> timestamps from packages).
> As mentioned before the clock seems to be stable when the application
> uses the own clock for an offset but now I would like to set the offset
> using an external source. I could probably query the external server
> itself.
>> In your case you will need to have a good lock on a reliable external
>> clock, and only *then* you take the timestamp and enable the gate
>> of your refclock.
>> When you don't do that, the ntpd will simply ignore your refclock
>> because it is a falseticker (a clock providing incorrect time).
>> ------------------------------
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/questions
>> End of questions Digest, Vol 114, Issue 63
>> ******************************************
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions

More information about the questions mailing list