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...>