I am now seeing better standard deviations with hardware timestamping than software timestamping. Thank you.
Couple of caveats: - I need to disable priority scheduling (-P). With priority scheduling, software stamps still have lower stddev. - I can only use a single ethernet interface. With multiple interfaces, software stamps still have lower stddev. I am still seeing issue strange offset issues. The view from 192.168.230.2: 210 Number of sources = 3 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 192.168.230.240 1 0 377 0 -20ns[ -21ns] +/- 13us ^+ 192.168.230.244 1 0 377 0 +71ns[ +71ns] +/- 13us =? 192.168.230.3 2 0 377 0 +9159ns[+9159ns] +/- 45us 210 Number of sources = 3 Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== 192.168.230.240 64 38 65 +0.000 0.001 +22ns 41ns 192.168.230.244 64 32 69 +0.000 0.001 -18ns 47ns 192.168.230.3 64 33 65 +0.001 0.001 +8851ns 58ns The view from 192.168.230.3: 210 Number of sources = 3 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 192.168.230.240 1 0 377 0 +5ns[ +6ns] +/- 13us ^+ 192.168.230.244 1 0 377 0 -32ns[ -32ns] +/- 13us =? 192.168.230.2 2 0 377 0 +15us[ +15us] +/- 51us 210 Number of sources = 3 Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== 192.168.230.240 16 8 15 +0.002 0.009 +24ns 45ns 192.168.230.244 22 9 21 -0.002 0.007 -25ns 48ns 192.168.230.2 16 7 53 -0.004 0.003 +12us 45ns Both crony instances think the other is off by a large amount. This disagreement is very stable. Denny > On Nov 23, 2016, at 01:40, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Fri, Nov 18, 2016 at 03:37:07PM +0100, Miroslav Lichvar wrote: >> On Thu, Nov 17, 2016 at 05:44:23PM -0800, Denny Page wrote: >>> Although reduced, I’m still seeing spikes with the patch below. >> >> I'm not sure what could be wrong at this point. Maybe it really is a >> kernel or HW issue. I'm wondering what would be the best way to >> confirm or reject that idea. > > I think I finally found what was causing the spikes for you. There was > a typo in the code that was processing raw PHC readings, which > effectively disabled filtering of delayed readings and added a > significant error to the PHC sample time. It explains why the results > I was seeing were not quite as good as I expected. Maybe because I'm > testing on a machine with a faster CPU, it looked more like noise than > spikes. > > It should be now fixed in git. Please test. If you were doing any > experiments comparing offsets between SW and HW timestamping, you will > probably need to start again as this bug effectively added an offset > of maybe 1-3 microseconds. I'm sorry it took so long to figure it out. -- 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.