On Thu, Aug 13, 2015 at 08:18:30PM +1200, Bryan Christianson wrote: > > > On 11/08/2015, at 11:56 pm, Miroslav Lichvar <[email protected]> wrote: > > > > 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. > > > > On MacOS, adjtime(NULL, &rem) is not supported.
I see. > To implement the above, requires 2 adjtime() calls, one to stop it and one to > restart it so I don't think there are any real benefits in doing this. I think with the new predicted drift error added to the adjtime() offset there could be some difference on servers. As for each client request there is one or more get_offset_correction() calls, the average offset of the clock might be worse than it would be with only drift removal updates restarting the adjustment. Maybe the interval used in the calculation of predicted_error should include the interval since the last drift removal timeout? That would make it independent from other restarts of the adjustment. -- 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].
