Good morning !
As I explained the issues with the PTP slave which is a PXE Boot server at the
same time last week, where the message occurs which says to increase the
tx_timestamp_timeout or the issue being likely a driver bug, I have installed
the latest sourceforge e1000e driver (version 3.4.1.1) which does not solve the
problem.
Now as we said it is not per se a driver bug. Due to the increase in network
traffic (we assumed) the PTP slave instance will be interrupted. However, I am
still left with a question.
At the moment the PTP slave gets interrupted due to its increase in network
traffic being sent from the same server, the PTP slave instance everytime
receives an offset of 36 seconds (TAI / UTC conversion?). Then; the PTP
instance tries to slew this down but right at the moment it is nearly properly
aligned again there occurs a ‘clock check’ message and the offset shoots up to
70+ seconds and won’t recover anymore; returning only clock check messages
every second and offsets which only drift further away.
This latter described behaviour is what bugs us the most, that PTP is unable to
recover itself and is only drifting even further away. How come PTP is
interrupted by network increase, gaining a 36 second offset, slewing down and
then when it nearly recovers returns a clock check message and shoots up its
offset and never recovers again?
If anyone could help me out on this that would be great! I am already working
on this for several days and can’t find a clue on how to solve this..
Jord
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
