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

2016-11-21 Thread Denny Page
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

2016-11-21 Thread Miroslav Lichvar
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 error is error. The IP layer may > have option headers. This is rare with IPv4, but not with IPv6. With TX

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

2016-11-21 Thread Denny Page
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

2016-11-21 Thread Denny Page
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

2016-11-21 Thread Miroslav Lichvar
On Mon, Nov 21, 2016 at 09:38:36AM -0800, Denny Page wrote: > 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 As I understand it, modern switches don't wait until they have whole

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

2016-11-21 Thread Denny Page
> On Nov 21, 2016, at 10:59, Miroslav Lichvar 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 error is error. The IP layer

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

2016-11-21 Thread Miroslav Lichvar
On Mon, Nov 21, 2016 at 11:25:10AM -0800, Denny Page wrote: > On Nov 21, 2016, at 10:59, Miroslav Lichvar wrote: > > So, in order to make this as simple as possible, we could make an > > assumption that received packets have the same format as transmitted > > packets. At

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

2016-11-21 Thread Denny Page
I checked this. It appears to be completely symmetrical at the switch level. For both the 1Gb and 100Mb ports, the delta I see for NTP packets is a very consistent 912ns on a 1Gb mirror port. This is exactly as expected: preamble: 56 bits SFD: 8 bits MAC dest: 48 bits MAC src: 48 bits

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

2016-11-21 Thread Denny Page
I would not have expected this, and I haven’t dug into it, but looking at the time to generate timestamps for pcap, I am seeing times of more than a second(!). I am wondering what happens if we get to the point of sending the next request before we have received the transmit timestamp for the

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

2016-11-21 Thread Denny Page
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 wrote: > > I may hard

[chrony-dev] chrony-2.4.1 released

2016-11-21 Thread Miroslav Lichvar
chrony-2.4.1 is now available. It's a bugfix release, which fixes a crash with the smoothtime directive when used with the leaponly option to perform a synchronised leap smear, processing of kernel timestamps on non-Linux systems, and few other bugs. The sources can be downloaded here: