William Unruh schrieb: > 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. > 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 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
_______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
