On 12/16/2021 9:04 AM, Martin Pecka wrote: > Hi PTP users. > > We bought a few PCIe network cards for testing, all with Intel chipsets > and supposedly supporting PTP. I succeeded running HW-stamping PTP L2 > client on a card with I350 chipset and igb driver. > > However, two of the cards have a problem. The symptoms are the same, > although one is 1GbE with Intel 82576 chipset running igb driver and the > other is 10GbE with Intel X540 running ixgbe driver. > > The timestamping capabilities for both look like this: >
What version of the kernel and drivers are you using? > $ ethtool -T eth2 > Time stamping parameters for eth2: > 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: 1 > Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on (HWTSTAMP_TX_ON) > Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) > ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) > ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) > > Most importantly, ptpv2-event is there, as well as HW stamping and HW > clock. So PTP should be satisfied, shouldn't it? But the synchronization > never happens. This is what I see running the client: > > $ sudo /usr/local/sbin/ptp4l -H -i eth2 -f > /etc/linuxptp/automotive-slave.cfg --step_threshold=0.001 -m -l7 | grep > -v config > ptp4l[1127.941]: interface index 5 is up > ptp4l[1127.941]: selected /dev/ptp1 as PTP clock > ptp4l[1127.941]: section item /var/run/ptp4l.announceReceiptTimeout now 0 > ptp4l[1127.941]: section item /var/run/ptp4l.delay_mechanism now 0 > ptp4l[1127.941]: section item /var/run/ptp4l.network_transport now 0 > ptp4l[1127.941]: section item /var/run/ptp4l.delay_filter_length now 1 > ptp4l[1127.941]: section item /var/run/ptp4lro.announceReceiptTimeout now 0 > ptp4l[1127.941]: section item /var/run/ptp4lro.delay_mechanism now 0 > ptp4l[1127.941]: section item /var/run/ptp4lro.network_transport now 0 > ptp4l[1127.941]: section item /var/run/ptp4lro.delay_filter_length now 1 > ptp4l[1127.942]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000 > ptp4l[1128.000]: port 1 (eth2): INITIALIZING to SLAVE on INIT_COMPLETE > ptp4l[1128.001]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on > INIT_COMPLETE > ptp4l[1128.002]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on > INIT_COMPLETE > ptp4l[1128.002]: port 1 (eth2): received link status notification > ptp4l[1128.002]: interface index 5 is up > ptp4l[1128.532]: port 1 (eth2): received SYNC without timestamp > ptp4l[1129.097]: port 1 (eth2): delay timeout > ptp4l[1129.532]: port 1 (eth2): received SYNC without timestamp > ptp4l[1129.532]: port 1 (eth2): have FOLLOW_UP 59819, expecting SYNC but > got FOLLOW_UP 59820, dropping So this is the X540 which is receiving the frames? The "SYNC without timestamp" means that the packet is received without a timestamp. Could you check the ethtool stats output and see if rx_hwtstamp_cleared is incrementing? Another possible check would be to use the test utility testptp and verify that the network device clock is actually incrementing. I believe "SYNC without timestamp" can occur if the reported timestamp is 0? > ptp4l[1130.282]: port 1 (eth2): delay timeout > ptp4l[1130.468]: port 1 (eth2): delay timeout > ptp4l[1130.532]: port 1 (eth2): received SYNC without timestamp > ptp4l[1130.532]: port 1 (eth2): have FOLLOW_UP 59820, expecting SYNC but > got FOLLOW_UP 59821, dropping > ptp4l[1130.866]: port 1 (eth2): delay timeout > ptp4l[1131.532]: port 1 (eth2): received SYNC without timestamp > ptp4l[1131.533]: port 1 (eth2): have FOLLOW_UP 59821, expecting SYNC but > got FOLLOW_UP 59822, dropping > ptp4l[1132.269]: port 1 (eth2): delay timeout > ptp4l[1132.532]: port 1 (eth2): received SYNC without timestamp > ptp4l[1132.533]: port 1 (eth2): have FOLLOW_UP 59822, expecting SYNC but > got FOLLOW_UP 59823, dropping > ptp4l[1132.770]: port 1 (eth2): delay timeout > > So SYNC packets are coming in, FOLLOW_UP packets are coming in (I see > them in wireshark), 2-step sync is on, yet ptp still isn't working. Why > is that? As I said, if I just swap the card in the client for another > one with I350 chipset, it works. So the master should be okay. The two > computers are directly connected via a cable, no switch in between them. > > I'm testing this with both server and client running the master branch > of linuxptp from sourceforge. > > To avoid out-of-order packets to be the source of the above mismatch, I > also decreased the number of RX queues to 1: > The root cause is likely that the packets are being received but not timestamped. So I don't think out of order packets is the problem. > $ sudo ethtool -L eth2 combined 1 > $ ethtool -l eth2 > Channel parameters for eth2: > Pre-set maximums: > RX: 0 > TX: 0 > Other: 1 > Combined: 8 > Current hardware settings: > RX: 0 > TX: 0 > Other: 1 > Combined: 1 > > That did not change anything. > > These are the master and slave configs: > > $ cat /etc/linuxptp/automotive-master.cfg > [global] > gmCapable 1 > priority1 248 > priority2 248 > logSyncInterval -3 > syncReceiptTimeout 3 > neighborPropDelayThresh 800 > min_neighbor_prop_delay -20000000 > assume_two_step 1 > path_trace_enabled 1 > follow_up_info 1 > transportSpecific 0x1 > ptp_dst_mac 01:80:C2:00:00:0E > network_transport L2 > delay_mechanism E2E > BMCA noop > serverOnly 1 > inhibit_announce 1 > asCapable true > inhibit_delay_req 1 > > $ cat /etc/linuxptp/automotive-slave.cfg > [global] > gmCapable 1 > priority1 248 > priority2 248 > logSyncInterval -3 > syncReceiptTimeout 3 > neighborPropDelayThresh 800 > min_neighbor_prop_delay -20000000 > assume_two_step 1 > path_trace_enabled 1 > follow_up_info 1 > transportSpecific 0x1 > ptp_dst_mac 01:80:C2:00:00:0E > network_transport L2 > delay_mechanism E2E > BMCA noop > clientOnly 1 > inhibit_announce 1 > asCapable true > ignore_source_id 1 > step_threshold 1 > operLogSyncInterval 0 > operLogPdelayReqInterval 2 > msg_interval_request 1 > servo_offset_threshold 30 > servo_num_offset_values 10 > hwts_filter normal > Could you try layer 3 UDP packets instead of L2? > I'm a bit clueless here. I checked by adding a log message that the > ioctl setting HWTSTAMP_FILTER_PTP_V2_EVENT does not error out. So > everything seems okay, yet the sync does not work. > > Thank you for any help or hint. > > Martin Pecka > Thanks, Jake _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
