Jake, Thanks for your quick response. I'm using a Intel Corporation 82574L NIC with the e1000e driver. The output of ethtool is as follows:
*Time stamping parameters for enp18s0:* *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)* PTP is restarted when the offset becomes too large, so I typically just see something like this as output: *Nov 8 15:46:15 SCS ptp4l: [1090.615] rms 20960156 max 474283141 freq +17951 +/- 13312 delay 364 +/- 5* *Nov 8 15:46:18 SCS phc2sys: [1093.253] rms 20912783 max 473202628 freq +593 +/- 10378 delay 16340 +/- 522* *Nov 8 15:47:51 SCS systemd: Stopping Synchronize system clock or PTP hardware clock (PHC)...* *Nov 8 15:47:51 SCS systemd: Started Synchronize system clock or PTP hardware clock (PHC).* *Nov 8 15:47:51 SCS systemd: Starting Synchronize system clock or PTP hardware clock (PHC)...* *Nov 8 15:47:52 SCS phc2sys: [1187.220] reconfiguring after port state change* *Nov 8 15:47:52 SCS phc2sys: [1187.220] selecting CLOCK_REALTIME for synchronization* *Nov 8 15:47:52 SCS phc2sys: [1187.220] selecting enp18s0 as the master clock* When I don't change the filtering back to HWTSTAMP_FILTER_ALL after starting PTP, I don't seem to have this issue. Though sometimes I do see messages timing out waiting for tx timestamp: *Nov 8 17:15:36 SCS ptp4l: [587.670] timed out while polling for tx timestamp* *Nov 8 17:15:36 SCS ptp4l: [587.670] increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug* *Nov 8 17:15:36 SCS ptp4l: [587.670] port 1: send peer delay response failed* *Nov 8 17:15:36 SCS ptp4l: [587.670] port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)* *Nov 8 17:15:36 SCS phc2sys: [587.733] port 00173c.fffe.02a89c-1 changed state* *Nov 8 17:15:36 SCS phc2sys: [587.733] reconfiguring after port state change* *Nov 8 17:15:36 SCS phc2sys: [587.733] selecting enp18s0 for synchronization* *Nov 8 17:15:36 SCS phc2sys: [587.733] nothing to synchronize* *Nov 8 17:15:40 SCS ptp4l: [591.672] port 1: FAULTY to LISTENING on INIT_COMPLETE* *Nov 8 17:15:41 SCS ptp4l: [593.458] port 1: new foreign master 00173c.fffe.02a8fc-1* *Nov 8 17:15:45 SCS ptp4l: [597.458] selected best master clock 00173c.fffe.02a8fc* *Nov 8 17:15:45 SCS ptp4l: [597.458] port 1: LISTENING to UNCALIBRATED on RS_SLAVE* *Nov 8 17:15:45 SCS ptp4l: [597.499] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED* *Nov 8 17:15:46 SCS phc2sys: [597.734] port 00173c.fffe.02a89c-1 changed state* *Nov 8 17:15:46 SCS phc2sys: [597.734] port 00173c.fffe.02a89c-1 changed state* *Nov 8 17:15:46 SCS phc2sys: [597.734] reconfiguring after port state change* *Nov 8 17:15:46 SCS phc2sys: [597.734] selecting CLOCK_REALTIME for synchronization* *Nov 8 17:15:46 SCS phc2sys: [597.734] selecting enp18s0 as the master clock* The only other timestamping that I'm trying to do is receipt of packets coming every 10ms from a different device - there is no additional transmit timestamping. The switch certainly has a lot of other network traffic coming in, though. It didn't occur to me that timestamping the receipt of all packets would be a significant enough performance hit in this case, so I suppose that could be an issue. Unfortunately, to get just the timestamps of the packets in question, I've only found that the most granular rx filter that will work is HWTSTAMP_FILTER_PTP_V1_L4_EVENT, but that isn't enough for PTP to my knowledge. Thanks, John On Thu, Nov 8, 2018 at 5:42 PM Keller, Jacob E <jacob.e.kel...@intel.com> wrote: > > -----Original Message----- > > From: UWbadgers16 [mailto:uwbadger...@gmail.com] > > Sent: Thursday, November 08, 2018 2:59 PM > > To: linuxptp-users@lists.sourceforge.net > > Subject: [Linuxptp-users] HWTSTAMP_FILTER_ALL > > > > I'm using v1.8 of Linux PTP on CentOS 3.10.0-693. In addition to using > the ptp4l > > service, I also have to hardware timestamp reception of packets coming > from another > > device. I use HWTSTAMP_FILTER_ALL to achieve this. When ptp4l initially > starts, it > > changes the policy to HWTSTAMP_FILTER_PTP_V2_EVENT. Once ptp4l has > finished its > > initial syncing of the clocks, I change the policy back to > HWTSTAMP_FILTER_ALL. > > > > What hardware are you using (and what driver?)? > > ptp4l should be using HWTSTAMP_FILTER_ALL if it's supported... What does > the output of ethtool -T <device> show for your ethernet device? > > > This works for awhile, but eventually I tend to see the offset become > too large. It > > seems that when I switch back to HWTSTAMP_FILTER_ALL, it causes ptp4l to > have > > trouble keeping the clocks synced. I make sure to only modify the rx > filter by issuing an > > iotcl(SIOCGHWTSTAMP) first, but it still has issues. > > Can you show us the ptp4l output you're seeing where the clocks drift > apart? And this only reproduces if you change to HWTSTAMP_FILTER_ALL? Is > the other application doing only receive timestamps? > > > > > My initial impression is that so long as I'm using HWTSTAMP_FILTER_ALL, > ptp4l > > should have the timestamps that it needs. Will changing this filter > setting after ptp4l > > has already started cause issues? I understand that the latest > development branch > > has a "hwts_filter" option that takes care of a lot of the work, and it > might fix this > > problem, but I'm a bit more locked into using v1.8 as it's already baked > into the > > CentOS 3.10.0-693 kernel. > > It should work properly, but there may be device specific limitations, or > possibly changing the timestamp mode could cause some changes to clock > settings. In most cases I would think that's simply a driver bug, but it > could be due to hardware restrictions/workarounds. > > It's also possible that simply using HWTSTAMP_FILTER_ALL causes extra > delays for the hardware.... > > Thanks, > Jake > > > > > Any help would be greatly appreciated. > > > > Best regards, > > John >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
