Alessandro Rubini authored Jun 12, 2017 and Adam Wujek committed Jun 22, 2017

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: Alessandro Rubini <rubini@gnudd.com>