On Thu, Dec 10, 2015 at 04:45:05PM +0000, Dennis Kong wrote: > a) My linux system time was off by a few hours when I introduced a > PTP device with a better clock (class and priority1/2). The BM > algorithm does select the other PTP device as the grandmaster, > changes that interface port state to UNCALIBRATED and then to SLAVE > and updates our system time. The process takes quite a while to > complete (40 sec?), one issue is that our system time is lagging > about 35 seconds behind the preciseorigintimestamp in the PTP > master's follow-up message. All the other interfaces (Master port > state) on our switch start sending our updated utc system time (with > 35 second lag) in the preciseorigintimestamp of the follow-up > messages and the grandmaster identity advertised is that of the > better PTP master). Any idea why there is a 35 second difference in > the preciseorgintimestamp of our follow-ups compared to the PTP > foreign master's?
Yes. The reason is that the GM is serving TAI, but your SW-BC is serving UTC. You *could* fix this by telling your GM to serve UTC instead. However, running a BC with SW time stamping doesn't make too much sense. You will introduce large errors into the time signal. It would be easier and better to simply forget the SW-BC and connect the clients to the GM using normal switches. > b) If I introduce a large offset either by changing my linux system > time or the PTP master's time (verified that preciseorintimestamp > has large offset compared to our UTC/preciseorigintimestamp), > linuxptp NEVER updates the system time and hence our > preciseorigintimestamp has not sycnhronized to that of the PTP > master. There seems to be something fundamentally wrong here with > my setup. It appears the ONLY time I can get linuxptp to > synchronize our system time to the PTP master is if I restart > linuxPTP. No further synchronization seems to be possible > afterwards. Look at the options called "first_step_threshold" and "step_threshold". These let you control how ptp4l handles a sudden, large offset. Thanks, Richard ------------------------------------------------------------------------------ _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
