Re: [chrony-dev] SW/HW timestamping on Linux

> On Jan 18, 2017, at 05:43, Miroslav Lichvar wrote: > Denny, > > there is apparently a new ioctl for measuring the offset between the > NIC clock and system clock, which is supported on some onboard NICs > (that share clock with the CPU?). It's called

Re: [chrony-dev] SW/HW timestamping on Linux

> On Jan 18, 2017, at 09:11, Denny Page <dennyp...@me.com> wrote: > > >> On Jan 18, 2017, at 05:43, Miroslav Lichvar <mlich...@redhat.com >> <mailto:mlich...@redhat.com>> wrote: >> Denny, >> >> there is apparently a new ioctl for measu

Re: [chrony-dev] SW/HW timestamping on Linux

> On Jan 18, 2017, at 23:28, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Wed, Jan 18, 2017 at 08:41:03PM -0800, Denny Page wrote: >> Tx -> Rx timestamp: >> Uncompensated3175ns (stddev 110ns) >> Compensated

Re: [chrony-dev] Nanosecond timestamps

> On Nov 7, 2016, at 15:04, Denny Page <dennyp...@me.com> wrote: > > For comparison, this is the view from the monitoring system (192.168.230.3): > > 210 Number of sources = 5 > MS Name/IP address Stratum Poll

Re: [chrony-dev] SW/HW timestamping on Linux

Things are working quite well with software timestamping. This is from my monitoring system: 210 Number of sources = 6 MS Name/IP address Stratum Poll Reach LastRx Last sample === ^?

Re: [chrony-dev] SW/HW timestamping on Linux

:45, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Thu, Nov 10, 2016 at 11:25:31AM -0800, Denny Page wrote: >> Miroslav, >> >> And D H? > > D means daemon, i.e. no SW or HW timestamp. The first one is for > transmit timestampt, the other one for re

Re: [chrony-dev] SW/HW timestamping on Linux

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. Denny

Re: [chrony-dev] SW/HW timestamping on Linux

The average offset is ~300ns. I would not expect there to be so much asymmetry with the switch, but I suppose anything is possible. If I enable hardware time stamps the offset jumps to ~2100ns. Denny > On Nov 11, 2016, at 02:22, Miroslav Lichvar wrote: > > This looks

Re: [chrony-dev] SW/HW timestamping on Linux

Setting noselect for all sources seems to have no impact on standard deviation. Disabling all forms of dynamic tic (CONFIG_HZ_PERIODIC=y) seems to have some effect in reducing the number of “D H”, but does not appear to have much of an impact on the standard deviation. I am returning

Re: [chrony-dev] SW/HW timestamping on Linux

Yes, I these on the monitoring system. For all servers/peers. Denny > On Nov 14, 2016, at 05:35, Miroslav Lichvar wrote: > > Do you see in measurements.log any entries with 'D K' and > '111 111 ' in the columns with tests results (i.e. were any 'D K' > measurements

Re: [chrony-dev] SW/HW timestamping on Linux

3: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

Re: [chrony-dev] SW/HW timestamping on Linux

That cured my issue with offset between the hosts. > On Nov 24, 2016, at 06:57, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Thu, Nov 24, 2016 at 06:46:36AM -0800, Denny Page wrote: >> I do not have xleave enabled. Can you explain more as to why you wo

Re: [chrony-dev] SW/HW timestamping on Linux

Miroslav, This is called a cut-through, and is not the default. The reason it isn’t the default is because it propagates invalid frames (runts, run-ons, crc errors, etc.) beyond the source port. Store and forward is the default. Cut-though generally doesn’t work with port speed mismatch and

Re: [chrony-dev] SW/HW timestamping on Linux

Miroslav, There is no correction necessary. The speed change itself does not have any impact because the transmission time is symmetrical. Given host A on a 1Gb link and host B on a 100Mb link: A -> Switch transmission time 754ns Switch -> B transmission time 7540ns Total time 8294ns

Re: [chrony-dev] SW/HW timestamping on Linux

Miroslav, We actually don’t know the length of the data at layer 2. We can’t even guarantee the length at layer 3. Dispensing with layer numbers from now on. We have three levels we have to concern ourselves with: Ethernet IP UDP The only layer we know the size of is the UDP layer. The

Re: [chrony-dev] SW/HW timestamping on Linux

> On Nov 21, 2016, at 10:59, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Mon, Nov 21, 2016 at 10:28:26AM -0800, Denny Page wrote: >> The only layer we know the size of is the UDP layer. The Ethernet layer can >> have VLAN tag. Yes, it’s only 32 bits, but e

Re: [chrony-dev] SW/HW timestamping on Linux

Miroslav, what version of the kernel are you using for testing? And what are you using for scheduling priority? Denny -- 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

Re: [chrony-dev] SW/HW timestamping on Linux

at the driver/kernel next. It may just be an inherent offset due to software timestamping. I may hard code a correction for the hardware timestamps in chrony for testing. Denny > On Nov 21, 2016, at 10:50, Denny Page <dennyp...@me.com> wrote: > > I am going to set up a span

Re: [chrony-dev] SW/HW timestamping on Linux

Perfect. Thank you. Denny > On Nov 22, 2016, at 07:34, Miroslav Lichvar wrote: > > I've pushed to the git an implementation of the idea I proposed > earlier, which assumes symmetric position of UDP data in received and > transmitted packets. You can modify the calculation

Re: [chrony-dev] SW/HW timestamping on Linux

I tested with that earlier. Almost all the timestamps were rejected. But I was using poll 0. I’ll have to test again with a longer polling interval. Denny > On Nov 22, 2016, at 07:43, Miroslav Lichvar wrote: > > Can you confirm that with the patch I sent you earlier >

Re: [chrony-dev] SW/HW timestamping on Linux

I still have one significant offset mystery with the latest version. In the tests described below, the following IP addresses are involved: 192.168.230.2 Linux box. igb0 connected to main switch at 1Gb. 192.168.230.3 Linux box. igb0 connected to main switch, speed as described in tests.

Re: [chrony-dev] SW/HW timestamping on Linux

I do not have xleave enabled. Can you explain more as to why you would expect to see such an offset without xleave? Thanks, Denny > On Nov 24, 2016, at 05:11, Miroslav Lichvar wrote: > > That suggests the interleaved mode is not working. Are the peers specified > with

Re: [chrony-dev] SW/HW timestamping on Linux

Lichvar <mlich...@redhat.com> 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 w

Re: [chrony-dev] SW/HW timestamping on Linux

Miroslav, Just to make sure I test correctly, would you mind creating a diff for a test version for me? One that a can plug a hard coded number of nanoseconds correction for just packet receive? Thanks, Denny > On Nov 21, 2016, at 17:26, Denny Page <dennyp...@me.com> wrote: > &

Re: [chrony-dev] SW/HW timestamping on Linux

Yes, all ports on the monitoring system are identical. The i354 is a 4 port chip, and all the ethernet ports on the monitoring unit are connected through that same chip. The general server has both I354 and I211 chips. I shut everything down on the server to conduct a test. It didn’t matter

Re: [chrony-dev] SW/HW timestamping on Linux

to have results. Denny > On Nov 16, 2016, at 00:53, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Tue, Nov 15, 2016 at 08:24:37PM -0800, Denny Page wrote: >> With the latest drop in the repo, I’m still seeing the wild spikes in the >> standard deviation with har

Re: [chrony-dev] SW/HW timestamping on Linux

To be clear, would I still expect to see ‘D H’ in the measurements log with this change? Thanks, Denny > On Nov 16, 2016, at 00:53, Miroslav Lichvar wrote: > > Hm, the fix helped with the spikes I was seeking. Did we rule out the > possibility that in your case the

Re: [chrony-dev] SW/HW timestamping on Linux

Miroslav, There is an additional issue, which is perhaps unrelated to the other issues discussed. Background: Each target IP is a hardware based NTP server. IPs 240 and 244 are across the switch. Chrony is synchronizing with these two IPs. Incremental latency from the switch is approximately

Re: [chrony-dev] SW/HW timestamping on Linux

;mlich...@redhat.com> wrote: > > On Thu, Nov 17, 2016 at 05:49:44PM -0800, Denny Page wrote: >> This port speed differential appears to result in a asymmetry in >> transmit/receive time which significantly affects the calculations. If I >> lock the monitor host port at 10

Re: [chrony-dev] SW/HW timestamping on Linux

Although reduced, I’m still seeing spikes with the patch below. Denny > On Nov 16, 2016, at 00:53, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Tue, Nov 15, 2016 at 08:24:37PM -0800, Denny Page wrote: >> With the latest drop in the repo, I’m still s

Re: [chrony-dev] SW/HW timestamping on Linux

Miroslav, I’ve found the issue with the 2.2us offset between a locally attached vs across the switch. It’s not the switch. The act of crossing the switch itself seems to be negligible. The problem appears to be one of asymmetry arising from port speed mismatch. The hardware NTP device uses

Re: [chrony-dev] SW/HW timestamping on Linux

Turns out that after I run it for longer period while, I see mixed D H and H H for test 5 as well. > On Nov 10, 2016, at 13:35, Denny Page <dennyp...@me.com> wrote: > > test 5 > - hw stamps on for igb0 > - ntp servers attached via igb0 enabled, server attached via igb3 d

Re: [chrony-dev] SW/HW timestamping on Linux

> On Nov 11, 2016, at 02:17, Miroslav Lichvar wrote: > > The mixed results in tests 3, 4 and 8 are not as expected, however. > Can you please try running one of those tests with 'acquisitionport > 1' in chrony.conf and post the debug output (after ./configure >

Re: [chrony-dev] SW/HW timestamping on Linux

and response messages since both are requested at the point of the outbound send. Denny > On Nov 15, 2016, at 02:07, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Mon, Nov 14, 2016 at 08:59:17PM -0800, Denny Page wrote: >> I tested with a usleep(100) following the sendms

Re: [chrony-dev] SW/HW timestamping on Linux

, 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 sec

Re: [chrony-dev] SW/HW timestamping on Linux

Miroslav, I found the problem. The hardware receive timestamps are incorrect. It doesn’t matter if there is a switch involved or not. NTP depends upon round trip latency being symmetrical for it’s accuracy, both in local network and in remote networks. To help ensure this, NTP uses preamble

Re: [chrony-dev] SW/HW timestamping on Linux

Thank you > On Apr 11, 2017, at 12:14, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Wed, Dec 07, 2016 at 11:26:19PM -0800, Denny Page wrote: >> Are you running linuxptp to manage the clock or letting it free-run? I have >> some ptp servers, but have

Re: [chrony-dev] SW/HW timestamping on Linux

Are you running linuxptp to manage the clock or letting it free-run? I have some ptp servers, but have been focused on testing ntp with chrony managing the clock. Thanks, Denny > On Apr 11, 2017, at 11:56, Miroslav Lichvar wrote: > > I've synchronised the system clock

Re: [chrony-dev] SW/HW timestamping on Linux

currently using those for the i210, but the i354 is completely different. Still at it. Denny > On Dec 7, 2016, at 23:04, Denny Page <dennyp...@me.com> wrote: > > On the offset issue… one of the benefits of having so many ports, and several > of hardware based NTP units (

Re: [chrony-dev] SW/HW timestamping on Linux

Also, would it be possible to allow hardware timestamps to be used on one interface, and software timestamps on another (without falling back to daemon timestamps)? Thanks, Denny -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email

Re: [chrony-dev] SW/HW timestamping on Linux

6 at 05:03:15PM -0800, Denny Page wrote: >> Unfortunately, I’ve not yet received any response on the Intel list. While >> it’s quite clear that both the i211 and i354 require some compensation, I >> don’t have a good way to determine it other than by shots in the dark.

Re: [chrony-dev] SW/HW timestamping on Linux

Btw, it might be good for Chrony to support configuration for corrections similar to what is discussed in that thread: delayAsymmetry - corrects for any asymmetry between the Rx and Tx paths egressLatency - corrects the transmit latency at the MAC/PHY ingressLatency - corrects the receive

Re: [chrony-dev] SW/HW timestamping on Linux

> On Dec 05, 2016, at 01:05, Miroslav Lichvar wrote: > > If I understand your change correctly, it increases the minimum > acceptable delay, which increases the number of combined readings and > makes the offset more stable. I'm worried on a busy system bad > readings could

Re: [chrony-dev] SW/HW timestamping on Linux

Here is an example of where I am at after the change: 210 Number of sources = 6 MS Name/IP address Stratum Poll Reach LastRx Last sample === ^* 192.168.230.240 1 0 377 0

Re: [chrony-dev] SW/HW timestamping on Linux

I’m still chasing the offset issue. However on the spikes/noise issue, the patch below addresses the noise and low level spikes that I was seeing. I was seeing errors of 2-60ns off in the average offset for the nic clock, which this corrects. I’m still seeing the occasional larger spike, but

Re: [chrony-dev] SW/HW timestamping on Linux

lav Lichvar <mlich...@redhat.com> wrote: > > On Mon, Dec 19, 2016 at 10:36:15PM -0800, Denny Page wrote: >> Yes, I think offset covers the delayAsymmetry feature. The other two, >> latency for tx and rx would be very, very helpful. Any chance of that >> happening prior

Re: [chrony-dev] [contrib] unidled: a linux idle management daemon for chronyd/gpsd

Andreas, Okay, that’s damn creative. A very interesting alternative to disabling power management. :) Kinda cool. One thing however... Comments from the code: * When using unidled, assert that all of gpsd, chronyd and unidled are set * to run on the same core and with realtime privilege

Re: [chrony-dev] Frequency transfer in NTP

Thank you for sending that out Miroslav. Very interesting read. Denny > On Jan 28, 2021, at 06:40, Miroslav Lichvar wrote: > > I guess most people here don't follow the NTP WG list. There is one > feature proposed for NTPv5 that I think would make a big difference > for chrony: > >

Re: [chrony-dev] Moving chrony website

> On Jul 26, 2023, at 07:05, Miroslav Lichvar wrote: > > On Mon, Jul 24, 2023 at 05:07:13PM -0700, Denny Page wrote: >> FWIW, it looks like chrony.net <http://chrony.net/> and chrony.org >> <http://chrony.org/> are just being camped on hoping for a quick sa

Re: [chrony-dev] Moving chrony website

I think this is a really good idea. FWIW, it looks like chrony.net and chrony.org are just being camped on hoping for a quick sale. Both are held by the same individual (Tampa FL), so it is likely either one or both domains could purchased for a small