linuxptp-users

[Linuxptp-users] shortly following DELAY_REQ from two slaves only trigger one DELAY_RESP (Intel 82579LM)

[Hanspeter P. <de...@op...>]

I have my time master (e1000e, Intel 82579LM) set up with hardware time
stamping.
Then I have two slaves set up with software timestamping (not using
linuxptp, microcontrollers).

When the two slaves send their delay requests shortly following each
other, often only one of both is answered.
For the ignored one, there is this error: 'ptp4l[16004.338]: port 1:
received DELAY_REQ without timestamp'

For the ignored delay request:
- 'fsm_event_port_event' returns -ETIME
- because 'transport_recv' reports a hardware time stamp of 0
- 'transport_recv' calls 'udp_rec' which calls 'sk_receive'
- there I've seen that the ignored delay request packet has no cmsg and
therefore no associated timestamp

Has anybody encountered similar issues?

Here the corresonding wireshark capture:
https://dl.dropboxusercontent.com/u/46882396/ptp4l.pcapng.gz

Hanspeter

Re: [Linuxptp-users] shortly following DELAY_REQ from two slaves only trigger one DELAY_RESP (Intel 82579LM)

[Vick, M. <mat...@in...>]

On 4/14/14, 12:23 PM, "Hanspeter Portner" <de...@op...>
wrote:

>I have my time master (e1000e, Intel 82579LM) set up with hardware time
>stamping.
>Then I have two slaves set up with software timestamping (not using
>linuxptp, microcontrollers).
>
>When the two slaves send their delay requests shortly following each
>other, often only one of both is answered.
>For the ignored one, there is this error: 'ptp4l[16004.338]: port 1:
>received DELAY_REQ without timestamp'
>
>For the ignored delay request:
>- 'fsm_event_port_event' returns -ETIME
>- because 'transport_recv' reports a hardware time stamp of 0
>- 'transport_recv' calls 'udp_rec' which calls 'sk_receive'
>- there I've seen that the ignored delay request packet has no cmsg and
>therefore no associated timestamp
>
>Has anybody encountered similar issues?
>
>Here the corresonding wireshark capture:
>https://dl.dropboxusercontent.com/u/46882396/ptp4l.pcapng.gz
>
>Hanspeter

Hanspeter,

Sorry to hear you're having trouble! I haven't had the chance to look over
the Wireshark capture, but typically that message in your setup (e.g. not
using linuxptp on the link partners and bursting the traffic) means that
the hardware simply cannot process the Rx timestamp requests quickly
enough. I'd recommend trying to space out the DELAY_REQ traffic a little
better if at all possible.

I've CC'd Dave Ertman, the e1000e maintainer, in case there's anything
further we can help with.

Cheers,
Matthew

Matthew Vick
Linux Development
Networking Division
Intel Corporation

Re: [Linuxptp-users] shortly following DELAY_REQ from two slaves only trigger one DELAY_RESP (Intel 82579LM)

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

On Mon, Apr 14, 2014 at 09:44:30PM +0000, Vick, Matthew wrote:
> On 4/14/14, 12:23 PM, "Hanspeter Portner" <de...@op...>
> wrote:
> 
> >I have my time master (e1000e, Intel 82579LM) set up with hardware time
> >stamping.

This card can only time stamp one packet at a time.

> >Then I have two slaves set up with software timestamping (not using
> >linuxptp, microcontrollers).
> >
> >When the two slaves send their delay requests shortly following each
> >other, often only one of both is answered.
> >For the ignored one, there is this error: 'ptp4l[16004.338]: port 1:
> >received DELAY_REQ without timestamp'
> >
> >For the ignored delay request:
> >- 'fsm_event_port_event' returns -ETIME
> >- because 'transport_recv' reports a hardware time stamp of 0
> >- 'transport_recv' calls 'udp_rec' which calls 'sk_receive'
> >- there I've seen that the ignored delay request packet has no cmsg and
> >therefore no associated timestamp
> >
> >Has anybody encountered similar issues?

This is to be expected. If two packets arrive at nearly the same time,
the 82579 will only be able to time stamp one of them, and one event
message will be dropped by linuxptp. However, this does not present a
problem because:

1. The slaves are required by the PTP to randomly distribute their
   requests, making the "collision" a rare event.

2. The synchronization algorithm is robust to occasional missing
   Delay_Req/Resp information. After all, the path delay does not
   change in typical environments.

Thanks,
Richard