[ntp:questions] Frequency adjustments in a local network

William Unruh unruh at invalid.ca
Fri Apr 4 21:10:01 UTC 2014

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. 

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

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. 

> Regards
> Maximilian
> Maximilian Brehm schrieb:
>> Hey NTP community, 
>> I need to synchronize only the frequency of a
>> destination systems based on the frequency of a reference system in the
>> same network. This is because the reference system does not supply
>> timestamps and they are not important for the destination system. So, I
>> would say I need (a) only frequency and no clock adjustments for the
>> destination system and (b) a method to synchronize clocks via a local
>> network. 
>> Are there ways to achieve this using NTP that are implemented
>> or may be implemented? If yes, can you recommend me starting points for
>> either way? 
>> Thanks 
>> Maximilian Brehm
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/questions

More information about the questions mailing list