| Re: [chrony-dev] SW/HW timestamping on Linux |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
- To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-dev] SW/HW timestamping on Linux
- From: Denny Page <dennypage@xxxxxx>
- Date: Mon, 21 Nov 2016 11:25:10 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1479756312; bh=2b3rzdTfQPPRibGCu6AlEL99OcV/82JYNTUOXAil8jE=; h=From:Content-type:MIME-version:Subject:Date:To:Message-id; b=EVtFVc7N8D+oI4/i2sH7agf4qu1MgmjrhvsPgEyduANDIrvgHZ85ftK/AM9Sdu61o Nr/YuO7OWai76tgk/0/HBOhvyDYwGyLs62efY3XYcb0/j010wdJvHwZSJY0JDYgXGK My+mwot0/fzcUlvyicEtpbun3k4FbHKxYq+d9YJ3OgDq5zLzB2C8UPPIDWE8nH5cvV 0YxzSkWluQUMdgoH2yG5sRLv3Qe/qBahRJl3GMdaXYdZZc0IdUKoNHLmHLVXdFdYK1 zvEANYXxtTrwBfCoE93ZlSEiTb+QgkKi1lAtmZfEZ7GIgBXl3nJx3mOhtqa2NRuE06 JPKD2M9jXVm3w==
> On Nov 21, 2016, at 10:59, Miroslav Lichvar <mlichvar@xxxxxxxxxx> 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 may have option headers. This is rare with IPv4, but not with IPv6.
>
> With TX timestamping the kernel gives us ethernet frames and we have to
> painfully extract the UDP data from them.
I didn’t know this. Thanks. If we already have the raw Ethernet frame in hand, then raw sockets are not necessary. I’ll have to look at the code.
> 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 least with VLANs this might work more often than not.
It really doesn’t have anything to do with the packet as we sent it. VLANS and IP options can be added along the way. We only need to look at the packet as received in order to correct the receive timestamp. The transmit timestamp is already correct.
>> The formula would be: timestamp += (ether_bytes + 4) * 8 / link_bps.
>
> Ok, so if we store offset of UDP data from the beginning of a
> transmitted frame at layer 2, it would be this?
>
> (udp_data_offset + NTP packet length + 4)
For the correction, we don’t care where the UDP data is. All we want is the length of the Ethernet frame. If this isn’t handed to us when we are given the raw frame, we can pull the length out of the frame. I’ll have to look at the code.
Denny
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.