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

Maximilian Brehm maximilian.brehm at tu-ilmenau.de
Wed May 7 14:23:46 UTC 2014

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 
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).

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.

More information about the questions mailing list