On Tue, Aug 11, 2015 at 10:26:44PM +1200, Bryan Christianson wrote: > 5 servers from each of the NZ and US pools - so combining is in effect. In > looking at our NZ servers (about 10ms round trip over my DSL link) I am > seeing about 1/2 the interval you suggest. If C1 (we need a better name) is > increased from 0.1 to say 0.25 than update interval should be pretty close to > the 5 - 10 sec range > > I have 3 servers on my LAN, including a stratum 1 USB GPS PPS that is good to > about 5 usecs - and thats close to the 'System time' I'm seeing on the Mac. > > I think this approach works quite well and a bit of fine tuning on the > constant should get a good compromise for typical use cases.
Ok. If no good compromise is found, there could be a "power saving" option that would set the minimum allowed update interval. BTW, when experimenting with multiple sources and longer drift removal intervals I think it might be useful to rework the get_offset_correction() function to not stop and restart the currently running adjustment, but only read the remaining offset with adjtime(NULL, &tv), so NTP measurements from sources other then the selected peer are not restarting the drift removal. This would also reduce the number of adjtime() calls, especially on a NTP server. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
