> On 4/08/2015, at 3:52 am, Miroslav Lichvar <[email protected]> wrote: > > On Thu, Jul 30, 2015 at 09:50:26AM +1200, Bryan Christianson wrote: >> The darwin kernel implementation of adjtime() does not require the >> adjustment to >> be aligned to a tickadj boundary, and we can apply adjustments to the >> nearest microsecond. >> Rounding is accounted for by adding any rounding errors back into the offset. > > Applied, thanks. What offset do you now see? I guess it doesn't solve > the problem you were trying to fix in your previous patch.
New graph at http://whatroute.net/chrony/ It's an order of magnitude better than chrony-2.1.1 and is looking pretty good. I have maxpoll, minpoll both set to 4 My machine had just been rebooted just before I took the screenshot, and you can see the initial offset of about 1 second rapidly converge to the order of -10 usec Graph legend green: Offset sd purple: frequency (ppm) red: rms offset blue: offset brown: System time orange: Weighted mean System Time (weighting 0.1) > > I was wondering if the error of the clock could be minimized by > including in the requested adjustment a prediction of the offset in > the middle of the update interval so the mean value is close to zero > if the drift doesn't change much. E.g. with a drift of 10 ppm and > current offset of 20 microseconds, request 25 microsecond adjustment > instead of 20, so the clock overshoots a bit and reaches zero offset > in about 0.5 seconds. > > Yes, I think something like that could work, although I think some low pass filtering would be required in calculating the overshoot. It would be making the system act more like a PID controller and I think it should be approached on that basis. > -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
