Skip to content
  • Alessandro Rubini's avatar
    syslog: tell not-critical track-lost events · 9d04f61f
    Alessandro Rubini authored and Adam Wujek's avatar Adam Wujek committed
    
    
    Under frame loss, most track-lost are just because of ptp timeouts.
    But since the underlying pll is unaffected, and the RTT is almost constant,
    we can tell in the logs whether the lost/resync was actually a time
    jump or not.
    
    This is what happens with moderate frame loss (fhe first track-lost is
    real, due to a ptp restart, the following ones are not and max delta
    between calculated setpoint and current setpoint is reported):
    
       Jan  1 00:00:02 192.168.128.84 (00: 26:7b:00:04:27) Node up since 1 seconds
       Jun 12 14:16:06 192.168.128.84 Tracking after 19.141 s
       Jun 12 14:17:14 192.168.128.84 Lost track
       Jun 12 14:17:20 192.168.128.84 2-th re-rtrack after 6.119 s
       Jun 12 14:17:43 192.168.128.84 Lost track
       Jun 12 14:17:46 192.168.128.84 3-th re-rtrack after 3.287 s (max delta 2 ps)
       Jun 12 14:18:48 192.168.128.84 Lost track
       Jun 12 14:19:00 192.168.128.84 4-th re-rtrack after 12.388 s (max delta 0 ps)
       Jun 12 14:19:14 192.168.128.84 Lost track
       Jun 12 14:19:18 192.168.128.84 5-th re-rtrack after 4.126 s (max delta 3 ps)
       Jun 12 14:19:25 192.168.128.84 Lost track
       Jun 12 14:19:31 192.168.128.84 6-th re-rtrack after 6.022 s (max delta 4 ps)
       Jun 12 14:19:36 192.168.128.84 Lost track
       Jun 12 14:19:38 192.168.128.84 7-th re-rtrack after 2.229 s (max delta 1 ps)
       Jun 12 14:19:52 192.168.128.84 Lost track
       Jun 12 14:20:03 192.168.128.84 8-th re-rtrack after 10.997 s (max delta 1 ps)
       Jun 12 14:21:02 192.168.128.84 Lost track
       Jun 12 14:21:21 192.168.128.84 9-th re-rtrack after 18.906 s (max delta 2 ps)
    
    Signed-off-by: default avatarAlessandro Rubini <rubini@gnudd.com>
    9d04f61f