[ntp:questions] Fwd: Re: Best ways to get the reference times from ntp
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
>> 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).
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