[Linuxptp-devel] out of order delay rsp

[Makarand Kulkarni]

The current ptp4l code handles out of order sync/fup messages

Shouldn't there be similar case for delay-req and delay-rsp ? In case
the delay timer is shorter than the roundtrip time,
code would send up another delay-req and when you get a response for the
previous one, the sequence numbers won't match causing this delay
response to be dropped

[Richard Cochran]

Post by Makarand Kulkarni
The current ptp4l code handles out of order sync/fup messages
Shouldn't there be similar case for delay-req and delay-rsp ? In case
the delay timer is shorter than the roundtrip time,
code would send up another delay-req and when you get a response for the
previous one, the sequence numbers won't match causing this delay
response to be dropped

Well, what you describe is surely possible, but I would not think that
this is a big deal, because:

1. The timing of the delay request is randomly chosen.

2. If one gets dropped now and again due to a short interval, this is
really not much different than having chosen a slightly longer
interval.

Thanks,
Richard

[Makarand Kulkarni]

Post by Richard Cochran

Post by Makarand Kulkarni
The current ptp4l code handles out of order sync/fup messages
Shouldn't there be similar case for delay-req and delay-rsp ? In case
the delay timer is shorter than the roundtrip time,
code would send up another delay-req and when you get a response for the
previous one, the sequence numbers won't match causing this delay
response to be dropped

Well, what you describe is surely possible, but I would not think that
1. The timing of the delay request is randomly chosen.
2. If one gets dropped now and again due to a short interval, this is
really not much different than having chosen a slightly longer
interval.

Somehow I missed this reply. It's not about dropping delay_req, it's
just that on sending
one, you don't receive a response so you timeout and again send one. Now
you get a response
for the old delay_req, but it is discarded since sequence number does
not match. SO you
send one more
On my system, for some reasons, the random gap is not so random, so just
kept on losing
the responses.

Post by Richard Cochran
Thanks,
Richard

[Richard Cochran]

Post by Makarand Kulkarni
Somehow I missed this reply. It's not about dropping delay_req, it's
just that on sending
one, you don't receive a response so you timeout and again send one.
Now you get a response
for the old delay_req, but it is discarded since sequence number
does not match. SO you
send one more
On my system, for some reasons, the random gap is not so random, so
just kept on losing
the responses.

That sounds strange.

Can you post the output of "ptp4l -l7" showing this behavior?

Thanks,
Richard