Open danglin44 opened 5 years ago
This patch backports some stuff from ptp4l head. It slows leak but there's still a problem.
This gPTP.cfg demonstrates problem:
[global] #
# twoStepFlag 1 gmCapable 1 priority1 248 priority2 248 domainNumber 0
clockClass 248 clockAccuracy 0xFE offsetScaledLogVariance 0x436A free_running 0 freq_est_interval 1 transparent 0 #
# logAnnounceInterval 0 logSyncInterval -3 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 6 delayAsymmetry 0 fault_reset_interval 4 neighborPropDelayThresh 800 min_neighbor_prop_delay -20000000 followUpReceiptTimeout 3 syncTxContTimeout 140 fault_badpeernet_interval 300 #
# assume_two_step 0 use_one_step 0 use_2_step_pdelay 1 logging_level 6 path_trace_enabled 1 follow_up_info 1 hybrid_e2e 0 tx_timestamp_timeout 1 use_syslog 1 verbose 0 summary_interval 6 kernel_leap 1 check_fup_sync 0 #
# pi_proportional_const 0.5 pi_integral_const 0.1 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.0000008 first_step_threshold 0.0000005 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 #
# transportSpecific 0x1 ptp_dst_mac 01:80:C2:00:00:0E p2p_dst_mac 01:80:C2:00:00:0E uds_address /var/run/ptp4l #
# network_transport L2 delay_mechanism P2P time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0
The main changes are to the clock priority and accuracy. This allows ports to become slaves when a device with a better clock accuracy is connected.
When a ksz9477 port operates in slave mode, the memory used by ptp4l grows without limit and eventually ptp4l crashes. Performance degrades when memory usage gets large.
This can be demonstrated with the EVB by editing /ptp/avb/gPTP.cfg. Change priority1 to 248 and clockAccuracy to 0xFE. Restart ptp4l with a couple of AVB devices connected. One should become master. Watch ptp4l memory usage grow in top.
I know the memory is being allocated by msg_allocate (malloc). However, it is difficult to tell why some messages aren't being recycled. Possibly, this is related to PTP errata for device and/or the loss of TX timestamps.