On 3/18/2022 3:40 AM, psy...@web.de wrote: > Hello, > > I have a problem with the high of the calculated path delay. I am using > hardware timestamping and thought I get values less than 20ns. But i > have values over 7.8µs is that normal? > I have also tested the usecase with an i210, there I got 250ns, but > these are also quite high. >
I think others have mentioned this. It sounds like a symptom of EEE. Have you disabled that? I believe i219 has EEE support and it may be enabled by default. You can check it with --show-eee and configure it with --set-eee This is the Energy Efficient Ethernet, which can impact things such as the path delay because the packet is delayed in hardware due to the low power link. I believe the i219 captures the timestamp in the MAC before it sends it to the PHY, so the low power mode in the PHY introduces a significant delay there. > Questions: > 1. why are the values of i219 and i210 so different? what does the path > delay depend on The path delay is a measure of the time it takes between Tx timestamp on one end to Rx timestamp on the other end. It depends on the network in between. Do you have a (non-TC) switch in between? Typically as long as the path delay is stable, it doesn't cause a significant issue whether its higher or lower. It does depend on the NIC design, because it depends on where in the transmit and receive pipelines the timestamps happen. Its possible that some difference in how the devices capture timestamps results in the larger gap. The i219 may be taking the timestamp earlier in the process of sending a packet, or later in the process of receiving the packet. > 2. if it depends only on the NIC, where can I find out which NIC is the > best one for hardware time stamping, which keywords in the datasheet are > important? Unfortunately this is very difficult to determine. The data sheets do have some discussion of the PTP functionality and information. I don't know if they have any detailed schematic data for this though. I typically recommend the i210 device based on the igb driver, as it had a focus on supporting 802.1AS features and has had a strong track record. > 3. Is there a driver problem or is it possible to change something at > the ptp-files to get better values? > For path delay? not unless the driver is buggy. The path delay is calculated by measuring the time it takes for a delay request packet to transit the network. > NIC: I2019-V rev 21 > driver: e1000e - 3.8.4-NAPI > Kernel:5.4.0-104-generic > > output of: ethtool -T enp0s31f6: > Time stamping parameters for enp0s31f6: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) > software-system-clock (SOF_TIMESTAMPING_SOFTWARE) > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > PTP Hardware Clock: 0 > Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on (HWTSTAMP_TX_ON) > Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > all (HWTSTAMP_FILTER_ALL) > ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) > ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) > ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) > ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) > ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) > ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) > ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) > ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) > ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ) > > I use a i219-Notebook with following command as a slave: sudo ptp4l -P > -H -l 7 -i enp0s31f6 -m -s > The "Master"-command is simmiliar just with another interface and > without -s. > Output: > ptp4l[183917.707]: selected best master clock 70ff76.fffe.1dea84 > ptp4l[183917.707]: port 1 (enp0s31f6): LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[183918.444]: port 1 (enp0s31f6): delay timeout > ptp4l[183918.445]: delay filtered 7358 raw 7319 > ptp4l[183918.707]: master offset 239333 s0 freq +45884 path delay > 7858 > ptp4l[183919.444]: port 1 (enp0s31f6): delay timeout > ptp4l[183919.445]: delay filtered 7358 raw 7422 > ptp4l[183919.707]: master offset 239368 s1 freq +45919 path delay > 7858 > ptp4l[183920.444]: port 1 (enp0s31f6): delay timeout > ptp4l[183920.445]: delay filtered 7349 raw 7345 > ptp4l[183920.708]: master offset -464 s2 freq +45455 path delay > 7849 > ptp4l[183920.708]: port 1 (enp0s31f6): UNCALIBRATED to SLAVE on > MASTER_CLOCK_SELECTED > ptp4l[183921.445]: port 1 (enp0s31f6): delay timeout > ptp4l[183921.445]: delay filtered 7349 raw 7336 > ptp4l[183921.709]: master offset -485 s2 freq +45295 path delay > 7849 > ptp4l[183922.445]: port 1 (enp0s31f6): delay timeout > ptp4l[183922.446]: delay filtered 7349 raw 7365 > ptp4l[183922.709]: master offset 27 s2 freq +45661 path delay > 7849 > ptp4l[183923.445]: port 1 (enp0s31f6): delay timeout > ptp4l[183923.446]: delay filtered 7340 raw 7330 > ptp4l[183923.709]: master offset 137 s2 freq +45779 path delay > 7840 > You'll notice that even with a 7 usec path delay, it still manages to adjust the offset and adjust the clock. You could verify the offset from master using the Net sync monitor feature to ensure the offset is as-reported. Hope this helps explain things. Thanks, Jake > > > _______________________________________________ > Linuxptp-users mailing list > Linuxptp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-users _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
