On Fri, 19 Jun 2020 at 15:15, Richard Cochran <[email protected]> wrote:
>
> On Fri, Jun 19, 2020 at 03:12:57PM +0300, Vladimir Oltean wrote:
> > Perhaps the most frustrating thing to me, after debugging that system
> > issue, is that ptp4l had all means necessary to detect a system issue,
> > but it preferred to remain oblivious to it.
>
> This is a production PTP stack and not an operating system validation
> tool.
>
> Thanks,
> Richard
So that's how you want to play it.
Why does it contain this code then?
if (flags == MSG_ERRQUEUE) {
struct pollfd pfd = { fd, sk_events, 0 };
res = poll(&pfd, 1, sk_tx_timeout);
if (res < 1) {
pr_err(res ? "poll for tx timestamp failed: %m" :
"timed out while polling for tx timestamp");
pr_err("increasing tx_timestamp_timeout may correct "
"this issue, but it is likely caused by a driver bug");
return -errno;
What business has ptp4l to say that TX timestamps not being delivered
within 1 ms to the application are indicative of a driver bug? You and
I know full well that there's a lot of hardware which simply can't
deliver timestamps that fast, and that there's nothing wrong with it.
No need to shame here, really.
Or this check, right below:
} else if (!(pfd.revents & sk_revents)) {
pr_err("poll for tx timestamp woke up on non ERR event");
return -1;
}
}
I mean, shouldn't happen, and if it does, it's not ptp4l's fault, right?
And what is with this hack?
check_fup_sync
Because of packet reordering that can occur in the network, in
the hardware, or in the networking stack, a follow up
message can appear to
arrive in the application before the matching sync message. As
this is a normal occurrence, and the sequenceID message field
ensures proper matching, the ptp4l program accepts out of order
packets. This option adds an additional check using the
software time stamps from the networking stack to verify that the
sync message did arrive first. This option is only useful if you
do not trust the sequence IDs generated by the master.
The default is 0 (disabled).
Why would the network stack need additional validation via software
timestamps? I mean, it's not ptp4l's fault that timestamps were not
delivered in the right order. I thought the linuxptp suite is trying
to be helpful instead of pedantic, I'm starting to change my opinion.
Thanks,
-Vladimir
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
