Re: [Linuxptp-users] Fixing offset jump at reset?

[<jor...@gm...>]

Hi Richard and Jacob,

The most interesting is that on RHEL7 the 36 second offset occurs after the tx_timestamp_timeout error and after that the offset only drifts further away. (After staying ‘synchronised’ in the 36xxxxxxxxx range for a little of time)

I had tried the exact same thing between two HP Z440 PC’s (including the exact same Ethernet adapter + driver) running Ubuntu (instead of RHEL7). The tx_timestamp_timeout erorr occurred also on this slave server when pushing an .iso of +-5GB over the Ethernet line, except it didn’t got an offset of 36 seconds, and it even re-synchronised after a while, while the RHEL7 slave only drifts further away when pushing a lot of network traffic from that PTP slave server over the network.

Jord

On 10 Aug 2018, at 17:11, Keller, Jacob E <jac...@in...> wrote:

>> -----Original Message-----
>> From: Richard Cochran [mailto:ric...@gm...]
>> Sent: Thursday, August 09, 2018 6:16 PM
>> To: Keller, Jacob E <jac...@in...>
>> Cc: Jord Pool <jor...@ou...>; Cliff Spradlin via Linuxptp-users
>> <lin...@li...>; Chris Caudle <ch...@ch...>;
>> Cliff Spradlin <csp...@wa...>
>> Subject: Re: Fixing offset jump at reset?
>> 
>>> On Thu, Aug 09, 2018 at 07:10:44PM +0000, Keller, Jacob E wrote:
>>> Would it make more sense to have some "timecounter_reset()" function,
>> which uses the current nsec value and just resets the internal cycles? Then, as
>> long as the timecounter was updated as close as possible to before the hardware
>> reset, we'd only lose a few cycles, instead of getting the UTC/TAI conversion.
>> 
>> I guess it makes some kind of sense.  BUT still the new time will be
>> wrong.  And now it will be subtly wrong.  Maybe that would be even
>> more harmful, because it degrades the time quality while papering over
>> the driver/HW issues.
>> 
>> Thanks,
>> Richard
> 
> I'm just thinking in terms of the fact that if a reset occurs, that hardware will simply have the wrong time now. It's faster for ptp4l to recover from a small offset, than it is for it to recover from a 36second offset.
> 
> Hmm.. I suppose one could argue "why is it resetting in the first place" though. Perhaps the driver is being overly aggressive about the reset, or "resetting" ptp functionality even when it didn't have a proper hardware reset.
> 
> Thanks,
> Jake
> 
> ------------------------------------------------------------------------------
> 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
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users