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

William Unruh unruh at invalid.ca
Wed May 7 16:32:22 UTC 2014


On 2014-05-07, Maximilian Brehm <maximilian.brehm at tu-ilmenau.de> wrote:
> 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).

Not much more. But, lets play. 
The short answer is no, ntpd cannot play this game. You are trying to
use A to discipline not only B but C as well but on machine B. Easiest
would be to have A discipline C on C. Ie, C also runs ntpd to discipline
itself. The biggest problem is that the way that ntpd disciplines the
clock is to change its rate. It has not idea of a "true rate" except
vial those offsets. But then C could discipline B. But this would also
get rid of the much greater rate accuracy of C and what would be
delivered to B would essentially be A's clock, filtered through C. 

So let us rephrase the question as follows-- We have a clock C with no
rate fluctuation at all. C's time is xT+y, where x and y are unknown,
but known to be constants to very high accuracy. T is UTC time. Is there
some way to determine the unknowns x and y using A to sufficient
accuracy to have C drive B with better accuracy than having A drive B. 


ntpd will not do that. ntpd is a memoryless system. All it does is to
drive the rate of the local clock depending on the local offset. 
chrony has a much longer memory so if A's reported time really is
randomly fluctuating in rate and offset around T, then chrony will
average those fluctuations for a long time (64 samples max) and could
thus drive A's fluctuations down. So using chrony on C to determine x
and y, and then using C to drive B ( using ntpd on B or chrony on B)
could control B much better than could A on its own. One is effectively
using C as a flywheel to average out the fluctuations in A. But of
course that does not help if the only calculations you are able to do is
on  B. One could write a program on B so as to run a virtual C clock on
B, and use that to discipline B. 

In any case, as far as I can see, neither chrony not ntpd can do what
you want. You would have to write your own routines based on either of those two
to do it (eg run a virtual clock on for C on B--ie to use the signals
from A to estimate x and y, and then use that to discipline B. 



More information about the questions mailing list