2018-02-13 19:36 GMT+01:00 Richard Cochran <richardcoch...@gmail.com>:
> On Tue, Feb 13, 2018 at 07:01:22PM +0100, Oliver Westermann wrote:
> > The issue is that the PHY only has two slots for timestamps, one for
> > outgoing packages and one for incoming packages. If the device in
> question
> > is a ptp master and has multiple slave, it sometimes happen that both
> > DELAY_REQ packages come in short succession, which results in the PHY
> > driver/interrupt handler being to slow to get all timestamps.
>
> This is actually a bug in your driver. If an incoming delay request
> misses a time stamp, no fault is generated. The *transmit* time stamp
> is still available, but your driver fails to fetch it.
>
Thank you for your hints, you pointed me in the right direction.
> This should not happen. You should fix your driver so that it always
> fetches the Tx time stamp after sending a marked packet. No interrupt
> is necessary.
>
I may have run into a design constraint which I understood now, hopefully.
The issue were to strict timeouts that sometimes ran into an issue.
The current process is like this:
- ptp4l sends a DELAY_REQ package into the network stack and sends a SKB to
retrieve the timestamp
- when the PHY handles it, it saves the timestamp and generates an interrupt
- the interrupt handler of my PHY reads seq_id and timestamp and places an
event with both into a queue
- the PHY worker fetches the SKBs and searches for matching events in the
queue
I added some tracing into ptp4l and my phy driver and measured the timings
over some minutes of PTP (with additional load on the network interface,
additional load on cpus, all timeouts set to 100ms, 2170 measurements):
send to interrupt, mean/standard deviation/max in ms: 2,97 / 1,48 / 12,85
interrupt to match: 0,55 / 0,16 / 6,86
send to match: 3,52 / 1,62 / 13,21
>From that perspective my tx_timestamp_timeout of 10ms was to short. I would
raise it to 18ms (~50% extra margin).
Is there a reason not to do this?
Thanks, Olli
2018-02-13 19:36 GMT+01:00 Richard Cochran <richardcoch...@gmail.com>:
> On Tue, Feb 13, 2018 at 07:01:22PM +0100, Oliver Westermann wrote:
> > The issue is that the PHY only has two slots for timestamps, one for
> > outgoing packages and one for incoming packages. If the device in
> question
> > is a ptp master and has multiple slave, it sometimes happen that both
> > DELAY_REQ packages come in short succession, which results in the PHY
> > driver/interrupt handler being to slow to get all timestamps.
>
> This is actually a bug in your driver. If an incoming delay request
> misses a time stamp, no fault is generated. The *transmit* time stamp
> is still available, but your driver fails to fetch it.
>
> > From a PTP perspective this is not a big issue: A single missing delay
> > measurement doesn't break a clock.
>
> Right.
>
> > But PTP4L threats this as a critical error, printing
> > "timed out while polling for tx timestamp",
>
> This should not happen. You should fix your driver so that it always
> fetches the Tx time stamp after sending a marked packet. No interrupt
> is necessary.
>
> Thanks,
> Richard
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
