[ntp:questions] Frequency adjustments in a local network

William Unruh unruh at invalid.ca
Tue Apr 8 21:47:52 UTC 2014

On 2014-04-07, Maximilian Brehm <maximilian.brehm at tu-ilmenau.de> wrote:
> William Unruh schrieb:
>> On 2014-04-04, Maximilian Brehm <maximilian.brehm at tu-ilmenau.de> wrote:
>>> Hey again,
>>> thanks for the feedback so far. From your messages I realize I should
>>> provide you with more information.
>>> I would like to adjust the real time clock frequency of the destination
>>> system. In the current setup the reference system has temperature
>>> independent oscillators with a known drift (up to +/-2ppm) and the
>>> destination system has standard computer oscillators (up to +/-100ppm).
>> There is a difference between "real time clock (RTC) which is a clock
>> chip in the bios, and the system clock of the operating system, which is
>> run from the computer oscillator, and is set from the RTC. 
> Thanks for the correction, so I actually meant the system clock. 
>>> The reference system supplies timestamps, however, they do not
>>> reference
>>> absolute time points but time points that are relative to the start of
>>> the system. The destination's clock is synchronized via NTP over the
>>> Internet and as mentioned incorrectly before, the destination system
>>> needs the absolute time. In the current implementation, the timestamps
>>> are already sent from the reference to the destination system for other
>>> purposes and may be used for clock synchronization.
>>> In a first approach (1), when the connection to the NTP servers
>>> drops, the destination's clock should be adjusted based on the
>>> reference
>>> system's timestamps (but with the absolute time). In a second approach
>>> (2), the NTP algorithm filter and adjustment algorithms should be
>>> improved based on the reference system's timestamps.
>>> The logic has to be implemented on the destination system using the
>>> timestamps from the reference system. Do you think that a refclock
>>> driver for (1) sufficient? And is there anything like (2) already
>>> implemented or is a rewrite of NTP required? Do you have any general
>>> ideas on either (1) or (2) or another one? PTP looks good but NTP is a
>>> necessessity.
>> I am afraid that I find your explanation more confusing than before. 
>> The way ntp works is to to use the offset between the time as stated by
>> the system, and the time as stated by the server/source to speed up or
>> slow down the clock in order to bring that offset to zero. Thus it
>> measures the offset and adjusts the rate of the clock. That means that
>> an offset aof 80 years say will drive it nuts (well actually it will
>> simply jump the clock). 
> Could not I just measure the offset in the destination system and add
> the offsets to the timestamps of the reference system before processing
> them?

You would not want the server altering its time given the time of a
client. Let the client figure out its own problems and solve them.

>> You could run an interrupt line to the system, and use say shm_pps to
>> look at the interrupt, get the subsecond offset from that interrupt, but
>> use the system time to the nearest second as the seconds. Ie, by
>> definition the offset is never more than .5 sec. This would discipline
>> the time by keeping the microseconds offset between the two as near zero
>> as possible, but ignore the seconds part of the offset. 
>> You could even write a routine using shm to do that. 
>> I suppose you could also rewrite ntp to use some remote server in that
>> way-- ie one in which the seconds part of the time from that remote
>> receiver was replaced by the nearest second from your local clock. 
>> Now, this would mean that you would have to use some other source at
>> boot up to get your clock to be accurate within a second before
>> switching to this new source. 
> I have to admit I do not understand you here. Is shm_pps already
> implemented? I believe it references the Shared Memory driver in
> conjunction with Pulse-Per-Second? In the NTP code I have not found
> these drivers working in conjunction. Does this work?
It is a separate program which reads a pps source and delivers the time
to the shm memory location for the ntp shm refclock driver to read. It
relies on the system having a second outside client to bring the system
to within 1/2 a second of the right time, and then uses the system
seconds to tack onto the timestamped microsecond from the pps source. 
Now, in your case, you do not care about the seconds.

The name is actually shmpps. Note that you would have to redo it so as
to get the microseconds from you bad server instead of from an interrupt
driven timestamping.
>>> Regards
>>> Maximilian

More information about the questions mailing list