On 2014-04-04, Maximilian Brehm <[email protected]> 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 >> [email protected] >> http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
