linuxptp-users

[Linuxptp-users] poll tx timestamp timeout

[David G. <dav...@po...>]

I've been running ptp4l as a master, and this cropped-up a few times in
the log last night.

I've increased 'tx_timestamp_timeout' to 10ms, but has happened a few
more times even when run with an increased priority such as:

  sudo nice -n -19 ptp4l -i eth2 -f gPTP.cfg

Could this be igb.ko slow on the up-take?



PS. Netgear gave me some WORKING beta firmware last night so I'm off and
running with 802.1AS.  I'll be a happy camper when they get 802.1Qat and
802.1Qav done.

-- 
David Gravereaux <dav...@po...>

Re: [Linuxptp-users] poll tx timestamp timeout

[Richard C. <ric...@gm...>]

On Tue, Aug 13, 2013 at 05:15:05PM -0700, David Gravereaux wrote:
> I've been running ptp4l as a master, and this cropped-up a few times in
> the log last night.

You are running your i210 as master with P2P, right?

What are you using for logSyncInterval and logMinPdelayReqInterval?

How often does this occur? Twice in twelve hours?

Which messages are affected, sync, peer delay request, or both?

> I've increased 'tx_timestamp_timeout' to 10ms, but has happened a few
> more times even when run with an increased priority such as:
> 
>   sudo nice -n -19 ptp4l -i eth2 -f gPTP.cfg

Changing the priority of ptp4l will have no effect (see below).

> Could this be igb.ko slow on the up-take?

When the i210 time stamps a transmitted event packet, it generates an
interrupt. The ISR then schedules a work callback which runs after the
next system tick.* The callback then delivers the time stamp to the
error queue of the process's socket.

* [Make sure tx_timestamp_timeout is long enough to account for this.]

Although the i210 can only handle one outstanding Tx time stamp, still
I don't see how any can go missing, since the ptp4l program always
waits for Tx time stamp before sending another event message.

I can think of two explanations.

1. The i210 simply fails to time stamp some event packets.
2. You are running a second program that generates event packets.

Thanks,
Richard

Re: [Linuxptp-users] poll tx timestamp timeout

[David G. <dav...@po...>]

On 08/14/2013 12:01 AM, Richard Cochran wrote:
> On Tue, Aug 13, 2013 at 05:15:05PM -0700, David Gravereaux wrote:
>> I've been running ptp4l as a master, and this cropped-up a few times in
>> the log last night.
> 
> You are running your i210 as master with P2P, right?

Yes

> What are you using for logSyncInterval and logMinPdelayReqInterval?

logSyncInterval         -3
logMinPdelayReqInterval 0

> How often does this occur? Twice in twelve hours?

16 times since 7:30 this morning.  Happened just a couple times last night.

> Which messages are affected, sync, peer delay request, or both?

Not sure. It causes the master to change to the switch, then it grabs it
back after it recovers.  I would assume a sync

$ sudo nice -n -19 ptp4l -i eth2 -f gPTP.cfg
ptp4l[88348.672]: driver changed our HWTSTAMP options
ptp4l[88348.672]: tx_type   1 not 1
ptp4l[88348.672]: rx_filter 1 not 12
ptp4l[88348.672]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[88348.672]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[88352.175]: port 1: new foreign master 0026f2.fffe.f25aa0-1
ptp4l[88354.672]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[88354.672]: selected best master clock a0369f.fffe.1cdd3b <-me
ptp4l[88354.672]: assuming the grand master role
ptp4l[88356.177]: selected best master clock 0026f2.fffe.f25aa0 <-switch
ptp4l[88356.177]: assuming the grand master role
ptp4l[95586.834]: poll tx timestamp timeout
ptp4l[95586.834]: port 1: send sync failed
ptp4l[95586.834]: port 1: MASTER to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[95588.864]: driver changed our HWTSTAMP options
ptp4l[95588.864]: tx_type   1 not 1
ptp4l[95588.864]: rx_filter 1 not 12
ptp4l[95588.864]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[95593.793]: port 1: new foreign master 0026f2.fffe.f25aa0-1
ptp4l[95594.864]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[95594.864]: selected best master clock a0369f.fffe.1cdd3b
ptp4l[95594.864]: assuming the grand master role
ptp4l[97678.318]: poll tx timestamp timeout
...


>> I've increased 'tx_timestamp_timeout' to 10ms, but has happened a few
>> more times even when run with an increased priority such as:
>>
>>   sudo nice -n -19 ptp4l -i eth2 -f gPTP.cfg
> 
> Changing the priority of ptp4l will have no effect (see below).

Good to know, thanks.

>> Could this be igb.ko slow on the up-take?
> 
> When the i210 time stamps a transmitted event packet, it generates an
> interrupt. The ISR then schedules a work callback which runs after the
> next system tick.* The callback then delivers the time stamp to the
> error queue of the process's socket.
> 
> * [Make sure tx_timestamp_timeout is long enough to account for this.]

$ grep ^CONFIG_HZ /boot/config-3.8.0-27-generic
CONFIG_HZ_250=y
CONFIG_HZ=250

period of 250Hz is 4ms    (interesting)

> Although the i210 can only handle one outstanding Tx time stamp, still
> I don't see how any can go missing, since the ptp4l program always
> waits for Tx time stamp before sending another event message.
> 
> I can think of two explanations.
> 
> 1. The i210 simply fails to time stamp some event packets.
> 2. You are running a second program that generates event packets.


I'm running locally on this workstation as a test before pondering how
to put this on a PC/104 embedded system connected to an HP Z3801A or
other GPS-disciplined oscillator for its real duty.

Thanks Richard.  I'm coming up to speed

-- 
David Gravereaux <dav...@po...>

Re: [Linuxptp-users] poll tx timestamp timeout

[Richard C. <ric...@gm...>]

On Wed, Aug 14, 2013 at 12:56:02AM -0700, David Gravereaux wrote:
> On 08/14/2013 12:01 AM, Richard Cochran wrote:
> 
> > Which messages are affected, sync, peer delay request, or both?
> 
> Not sure. It causes the master to change to the switch, then it grabs it
> back after it recovers.  I would assume a sync

You can see this in the log on the line after the failure ...

> ptp4l[88356.177]: assuming the grand master role
> ptp4l[95586.834]: poll tx timestamp timeout
> ptp4l[95586.834]: port 1: send sync failed
                                 ^^^^
here.

> >> I've increased 'tx_timestamp_timeout' to 10ms, but has happened a few
> >> more times even when run with an increased priority such as:

...

> $ grep ^CONFIG_HZ /boot/config-3.8.0-27-generic
> CONFIG_HZ_250=y
> CONFIG_HZ=250
> 
> period of 250Hz is 4ms    (interesting)

So 10 ms might not be enough for this system. Try 100 ms.

Thanks,
Richard

Re: [Linuxptp-users] poll tx timestamp timeout

[David G. <dav...@po...>]

On 08/14/2013 01:25 AM, Richard Cochran wrote:
...
> So 10 ms might not be enough for this system. Try 100 ms.
> 
> Thanks,
> Richard
> 

Not one blip since last night, thanks.

-- 
David Gravereaux <dav...@po...>