[Linuxptp-devel] ptp can't recovery when unplug the cable and plug in after a while

[Arnold kang]

Hi, all
when I test linuxptp. I unplug the cable and plug in after a while,
the ptp can't recovery. and precision stay bad. any one know why?

[Richard Cochran]

Post by Arnold kang
when I test linuxptp. I unplug the cable and plug in after a while,
the ptp can't recovery. and precision stay bad. any one know why?

What driver and HW are you using?

Some of the Intel drivers reset the NIC time when the link goes down.

Thanks,
Richard

------------------------------------------------------------------------------

[Arnold kang]

Dear Richard,
thanks for your reply. I'm using AR8031, and hardware timestamp mode
. OS version: 3.0


some detail:
{359.993454} [DEBUG] master offset 2461 s2 freq -51098 path delay
32041

{360.380834} [DEBUG] t1 +1439307277796976619

{360.380880} [DEBUG] t2 +1439307277797011121

{360.380910} [DEBUG] t3 +1439307278181855128

{360.380936} [DEBUG] t4 +1439307278181898350

=====================================================
here I unplug the cable and after 23 seconds, I plugged in again
=====================================================


{388.939073} [WARNING] clockcheck: clock jumped backward or running slower
than expected!
{392.768454} [WARNING] foreign master not using PTP timescale
{392.990924} [DEBUG] origin [c->t1]+1439307310797676053

{392.990981} [DEBUG] ingress[c->t2]+1439307295457580057

{392.991013} [DEBUG] c->path_delay +0

{393.780969} [DEBUG] t1 +1439307310797676053

{393.781018} [DEBUG] t2 +1439307295457580057

{393.781047} [DEBUG] t3 +1439307296244987555

{393.781074} [DEBUG] t4 +1439307311585147610

{393.990981} [DEBUG] origin [c->t1]+1439307311797823009

{393.991025} [DEBUG] ingress[c->t2]+1439307296457725820

{393.991053} [DEBUG] c->path_delay +32029

{393.991080} [DEBUG] master offset -15340129218 s0 freq -51098 path delay
32029

Post by Richard Cochran

Post by Arnold kang
when I test linuxptp. I unplug the cable and plug in after a while,
the ptp can't recovery. and precision stay bad. any one know why?

What driver and HW are you using?
Some of the Intel drivers reset the NIC time when the link goes down.
Thanks,
Richard

[Richard Cochran]

Post by Arnold kang
Dear Richard,
thanks for your reply. I'm using AR8031, and hardware timestamp mode
. OS version: 3.0

That HW is not present in mainline Linux, and so I cannot help you
with it. Probably it is buggy.

Also, from the ptp4l output, someone has hacking around with it as
well. All bets are off.

You should ask your vendor to fix this issue.

Sorry,
Richard

------------------------------------------------------------------------------

[Arnold kang]

thank you! I'm trying to reset all ptp dataset when announce packet not
received. hope this work.

Post by Richard Cochran

Post by Arnold kang
Dear Richard,
thanks for your reply. I'm using AR8031, and hardware timestamp

mode

Post by Arnold kang
. OS version: 3.0

That HW is not present in mainline Linux, and so I cannot help you
with it. Probably it is buggy.
Also, from the ptp4l output, someone has hacking around with it as
well. All bets are off.
You should ask your vendor to fix this issue.
Sorry,
Richard

[Arnold kang]

Dear Richard,
I know why, when the cable unplugged , the rtc in phy still run as list
freq set. so after some seconds, the phy is slower or faster than master .
when cable plug in, after a very lone time to adjfreq, the ptp will sync.
but how to resolve this? how to recovery as soon as cable plugged in? any
advice?

thanks.

Post by Arnold kang
thank you! I'm trying to reset all ptp dataset when announce packet not
received. hope this work.

Post by Richard Cochran

Post by Arnold kang
Dear Richard,
thanks for your reply. I'm using AR8031, and hardware timestamp

mode

Post by Arnold kang
. OS version: 3.0

That HW is not present in mainline Linux, and so I cannot help you
with it. Probably it is buggy.
Also, from the ptp4l output, someone has hacking around with it as
well. All bets are off.
You should ask your vendor to fix this issue.
Sorry,
Richard

[Richard Cochran]

Post by Arnold kang
I know why, when the cable unplugged , the rtc in phy still run as list
freq set. so after some seconds, the phy is slower or faster than master .
when cable plug in, after a very lone time to adjfreq, the ptp will sync.
but how to resolve this? how to recovery as soon as cable plugged in? any
advice?
{359.993454} [DEBUG] master offset 2461 s2 freq -51098 path delay 32041
=====================================================
here I unplug the cable and after 23 seconds, I plugged in again
=====================================================
{393.991080} [DEBUG] master offset -15340129218 s0 freq -51098 path delay 32029

Before the link goes down, your offset is 2.5 usec. After the link
reappears, your offset is more than 15 seconds. The clock cannot
drift 15 seconds away in only 23 seconds real time.

Something else is broken, probably the driver, or the HW, or both.

Maybe you can work around this issue using the 'step_threshold'
configuration option.

Good luck,
Richard


------------------------------------------------------------------------------

[Arnold kang]

thanks. i'll try tomorrow!

Post by Arnold kang

Post by Arnold kang
I know why, when the cable unplugged , the rtc in phy still run as

list

Post by Arnold kang
freq set. so after some seconds, the phy is slower or faster than master

.

Post by Arnold kang
when cable plug in, after a very lone time to adjfreq, the ptp will sync.
but how to resolve this? how to recovery as soon as cable plugged in?

any

Post by Arnold kang
advice?
{359.993454} [DEBUG] master offset 2461 s2 freq -51098 path

delay 32041

Post by Arnold kang
=====================================================
here I unplug the cable and after 23 seconds, I plugged in again
=====================================================
{393.991080} [DEBUG] master offset -15340129218 s0 freq -51098 path

delay 32029
Before the link goes down, your offset is 2.5 usec. After the link
reappears, your offset is more than 15 seconds. The clock cannot
drift 15 seconds away in only 23 seconds real time.
Something else is broken, probably the driver, or the HW, or both.
Maybe you can work around this issue using the 'step_threshold'
configuration option.
Good luck,
Richard