Hi again, Latest update below ...
> -----Original Message----- > From: Hutchinson, Brian (US) - PSPC > Sent: Wednesday, October 13, 2021 10:32 AM > To: Vladimir Oltean <olte...@gmail.com> > Cc: linuxptp-users@lists.sourceforge.net; Christian Eggers <cegg...@arri.de> > Subject: RE: [EXTERNAL] Re: [Linuxptp-users] Using G.8275.2 profile and > getting tx timestamp timeout, but changing logSyncInterval etc. changes how > often this happens > > Hi Vladimir, > > > > -----Original Message----- > > From: Vladimir Oltean <olte...@gmail.com> > > Sent: Tuesday, October 12, 2021 7:11 PM > > To: Hutchinson, Brian (US) - PSPC <brian.hutchin...@l3harris.com> > > Cc: linuxptp-users@lists.sourceforge.net; Christian Eggers > > <cegg...@arri.de> > > Subject: [EXTERNAL] Re: [Linuxptp-users] Using G.8275.2 profile and > > getting tx timestamp timeout, but changing logSyncInterval etc. > > changes how often this happens > > > > On Fri, Oct 08, 2021 at 03:22:10PM +0000, Brian.Hutchinson--- via > > Linuxptp- users wrote: > > > Hi, > > > > > > I'm using Christian's DSA patches > > > https://lkml.org/lkml/2020/10/19/633) on a NXP iMX8MM with a > > > Microchip > > > ksz9567 with ptp4l.conf setup for E2E G.8275.2 profile. I'm running > > > a 1G RGMII interface and my GM and unit under test is connected via > > > a 1G Netgear dumb switch. > > > > > > Using 5.10.32 kernel with CONFIG_HZ_1000 and nohz=off on cmdline. > > > > > > I've been getting the "timed out while polling for tx timestamp" > > > error which causes linuxptp to restart. When linuxptp restarts my > > > 1PPS (generated from Microchip switch) walks all over the place on > > > my O Scope until linuxptp gets a good sync again and pulls 1PPS back > > > into sync with the GM sync out reference I'm also watching on the scope. > > > > > > Of course increasing tx_timestamp_timeout doesn't appear to help in > > > this case. I've tried values all the way up to 8000. > > > > > > But I can significantly reduce the frequency of the problem if I > > > make changes to some ptp4l.conf settings. > > > > > > With ptp4l.conf settings: > > > > > > logAnnounceInterval 1 > > > logSyncInterval 0 > > > logMinDelayReqInterval 0 > > > logMinPdelayReqInterval 0 > > > announceReceiptTimeout 2 > > > > > > I'll see the tx timestamp timeout probably 15 or so times running a > > > test overnight. > > > > > > If I set : > > > > > > logAnnounceInterval 1 > > > logSyncInterval 2 > > > logMinDelayReqInterval 2 > > > logMinPdelayReqInterval 2 > > > announceReceiptTimeout 2 > > > > > > ... then I might see tx timestamp only once or twice on an overnight run. > > > > > > I read a comment from Douglas Arnold from Meinberg that if basically > > > anything goes wrong with fulfilling a grant, message rate or grant > > > duration, or both, should be reduced. > > > > > > I've searched the archives and read all of the responses and a few > > > caught my attention. Most say it's a driver bug but some said it > > > could be a stack issue. So I'm wondering since I can significantly > > > decrease the occurrence of the tx timeout by modifying above > > > settings, what other settings would affect or tune this particular > > > telco profile? > > > > > > I'm still fairly new to all this and I understand the telco profiles > > > are a bit unique so I'm trying to understand what ptp4l.conf > > > settings I need to focus on for this particular profile. > > > > > > If this is a "stack" issue, what can I do to reduce the "message rate" > > > or "grant duration" if these are related to whatever a "stack" issue > > > is? > > > > I'd be willing to put my money on a driver bug. But for that you'd > > need to confirm that the issue reproduces with the default.cfg and not > > just with the > > G.8275.2 profile. Don't try to run before you can walk. So I ran tests using a plain 1588 profile and E2E and yes the problem still happens. Here is that config: [global] # # Default Data Set # twoStepFlag 0 slaveOnly 1 priority1 128 priority2 128 domainNumber 0 #utc_offset 37 clockClass 6 #clockClass 255 #step_window 48 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison ieee1588 #for G.8275.1 #dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval 1 logSyncInterval 0 logMinDelayReqInterval 0 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -128 #fault_reset_interval 4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 #tx_timestamp_timeout 300 tx_timestamp_timeout 1000 unicast_listen 1 unicast_req_duration 300 #unicast_master_table 1 use_syslog 1 verbose 0 summary_interval 4 kernel_leap 1 check_fup_sync 0 # # Servo Options # #servo_offset_threshold 100 #servo_num_offset_values 64 pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 0.0 #step_threshold 0.00002 first_step_threshold 0.00002 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 #udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type OC network_transport UDPv4 #delay_mechanism P2P delay_mechanism E2E time_stamping p2p1step #time_stamping onestep #time_stamping hardware #tsproc_mode filter #tsproc_mode raw tsproc_mode raw_weight delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 #maxStepsRemoved 255 # #[unicast_master_table] #table_id 1 #logQueryInterval 2 #UDPv4 192.168.0.250 #UDPv4 192.168.1.250 # #[lan1] #unicast_master_table 1 And I did find a bug in the DSA driver but it didn't appear to change anything. In ksz9477_ptp_txtstamp_skb function the "ret" that is being assigned by "wait_for_completion_timeout" returning is declared as an "int" instead of an "unsigned long" so I fixed that. ... still looking for other stuff but again, I'm probably not experienced enough (yet) with DSA and LinuxPTP to do much good. Regards, Brian CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving. _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
