With the latest drop in the repo, I’m still seeing the wild spikes in the standard deviation with hardware time stamping against the fast responding hardare units. I'm also still seeing a better base deviation using software timestamps against them as well.
I do see better results with hardware time stamping when doing chrony to chrony, but I believe that this is a result of the general purpose computers being a bit slower to respond than the dedicated hardware units. Denny > On Nov 15, 2016, at 05:58, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Mon, Nov 14, 2016 at 03:40:32PM +0100, Miroslav Lichvar wrote: >> On Sat, Nov 12, 2016 at 10:36:55AM -0800, Denny Page wrote: >>> Here is a reasonable visual representation of what I am seeing. The section >>> on the left (before 8:00) is with hardware timestamping, while the section >>> on the right is with software timestamping. maxdelaydevratio of 4 in both >>> cases. >>> >>> I think I have a kernel/driver problem. >> >> I think I see something similar. Occasional spikes that are causing >> resets of the HW clock instance. It looks like a chrony bug. > > This should be now fixed in git. > > -- > Miroslav Lichvar > > -- > To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
