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

mike cook michael.cook at sfr.fr
Wed May 7 17:07:57 UTC 2014


Le 7 mai 2014 à 16:23, Maximilian Brehm a écrit :

> First of all, sorry for the formatting issues. I will follow your recommendations and try to avoid this in the future. Answers to mike cook's and William Unruh's mails are below.
> 
> mike cook wrote:
>>  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. 
> 
> Almost, if I understand you correctly. Here is a problem description that clarifies it hopefully:
> Let's assume in a simple setup we have 3 systems A, B, and C. A is a NTP server (stratum 1 or 2) on the internet, B is a local server with a standard oscillator, and C is a system in the same network as A with a temperature-stable oscillator (and a known frequency offset in ppm). C does not provide absolute timestamps but only timestamps relative to an unspecific epoch (e.g. its starting time). C sends B those timestamps and on arrival they may be passed to NTP or another program via a sufficient interface (e.g. shared memory). The system clock of B is synchronized via NTP with A as server.
> The accuracy (difference compared to UTC, under 1ms and lower even in the initial phase of NTP would be ideal) and stability (how closely the clock maintains its frequency) of the clock in B is to be improved. The initial idea was to use the relative timestamps of C in B (a) via PPS or (b) as a refclock via the shared memory interface. I have not figured out a way to approach (a) but am working (b). As the timestamps from C are likely relative to another epoch than 1. January 1900 and the clock in C drifts, before the timestamps are passed to NTP in B, an offset has to be determined. This offset has to be adjusted (each timestamp or frequently when out of a specific threshold) as the oscillator in C has a drift. For example: A simplified procedure works when I do not use an external NTP server but synchronize to the local clock via clock_gettime with CLOCK_REALTIME and an offset (to simulate another clock than the system clock). That is, determine the epoch offset by using two timestamps that were approximately generated at the same time (this should approximately be the difference of 1. January 1970 plus offset to the epoch used in C). The frequency drift in C I havn't respected in this setup. The quality of this solution I havn't determined.
> For receiving the timestamps of A I implemented a call to 'ntpq -c "rv 0 clock"'. What do 0, &1, &2, and so on for rv actually reference? When I look at the output of 'ntpq -c "association"' I get assid's with 5 digits. When using multiple servers in NTP, this procedure has to be adjusted, of course.
> Do you think (a) or (b) may be actually working? Do you have other ideas? I guess another option would be to buy a cheap GPS clock for B and use it as refclock and PPS source but that would be just too easy (and a little more expensive).
> 

 Thanks for taking the time to clarify. 
  Solution a), using GPS with a 1PPS source is going to get you better quality if you can get a good antenna sky view, and your system B has the hardware to take the interrupt. Using the NMEA strings can only get you so close, not usec precission IMHO. As to being more expensive, I am not so sure. How do you cost your time?
  Solution b) defining C as a shm refclock, via a driver which normalizes the  timestamps from C should be doable( but may not hit the objectives ), and I think that you should let NTP do the hard work. 
How about this?
    As a first test compare the NTP stats of B with NTP referencing A (and any other servers you want to add redundancy). Who knows, maybe you can hit your objectives without referencing C at all.
    Second, try as I suggested, On A, when you start your driver, get Cs timestamp, get the current system clock value, convert Cs timestamp to a time_t ( you need to know the frequency of update , ie which bit gets incremented each second). Then you can take that from the system clock value, giving you an base offset which should equate to the UTC  boot time of C.  You might want to run a calibration loop over a number of C's timestamps to see if the result is stable. If it isn't then at least the spread  of values will give you an idea of quality. After that, loop doing
at each timestamp arrival do the same sums. If C has no drift, then the result will remain the same, if it changes, then you will have C's drift with respect to B's system clock , which you will have to adjust according to the quality from your calibration phase.  Now you can adjust the system clock value accordingly, format it as required in the shm refclock's shared memory. My own feeling is , that with variable network delays in receiving timestamps from C, you will be pushed to do better than NTP can referencing A. 
 You will probably want to run the refclock with a high stratum during tests to see how it is performing with respect to A and any other servers yo configure on B.
 


> William Unruh wrote:
>> It is very unclear what your mean (and I do not just mean the
>> formatting). Is this an external clock to the computer? Do you at least
>> know that the clock starts on the second, or is the start time unknown
>> even to the microsecond level? Why do you want to use that clock?
>> "It works well when setting its offset to the system clock"
>> What works well? Are you trying to get that relative clock to have the
>> correct time, or is it providing the time?
>> Yes, ntpd would find it very very difficult to use that clock as a
>> reference. A PPS signal which has not seconds marker, at least is know
>> to be accurate to the ms, and it can be used to discipline the system
>> clock to the ms, if something else disciplines the seconds. Your give
>> nothing except the rate, and ntpd uses only the offset to determine the
>> rate.
> 
> Thanks for your patience with me and my imprecise descriptions. I hope the above answer clarifies what I actually mean.
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions


More information about the questions mailing list