[ntp:questions] Frequency adjustments in a local network

Maximilian Brehm maximilian.brehm at tu-ilmenau.de
Mon Apr 7 09:50:31 UTC 2014

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
> 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?
>> Regards
>> Maximilian

More information about the questions mailing list