> -----Original Message-----
> From: Richard Cochran <richardcoch...@gmail.com>
> Sent: Monday, July 12, 2021 6:44 PM
> To: Keller, Jacob E <jacob.e.kel...@intel.com>
> Cc: Miroslav Lichvar <mlich...@redhat.com>; linuxptp-
> de...@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH] Increase the default
> tx_timestamp_timeout
> to 5
>
> On Mon, Jul 12, 2021 at 03:02:50PM +0000, Keller, Jacob E wrote:
>
> > Right. Though.. running something like ptp4l on the same connection
> > could be problematic if the applications aren't working together
> > because most hardware supports a single request at once,
>
> I wouldn't say "most". Surely some HW is like that, but I never
> counted. I always hoped that HW designers would get a clue a simply
> provide a time stamp for each and every frame, Tx and Rx, in the
> buffer descriptors. No filters, no parsers, just a big on/off switch.
> It would be way easier to implement in HW, and it would solve all of
> these sorts of problems.
>
The hardware I've seen at least. (Ofcourse, I suppose I am Intel biased here...)
I think there's two issues here:
For receive, I think the issue was a belief that the cost in bytes to store the
timestamp would be too high. This turns out to either be not true, or not
important because the demand for useful timestamps is high enough to account
for it. (Newer hardware has opted to simply add timestamping for all frames).
I think for Tx the challenges are higher: the timestamp is taken after we've
filled in the descriptor and sent the frame. The only place it could reasonably
be stored again is the descriptor writeback (since we don't get completion
messages). If I remember correctly, the challenge here is that in a traditional
ring model the writeback is completed much earlier than the timestamp so we
potentially delay cleanup of other packets by waiting to insert the timestamp
into the writeback.
I'm not sure entirely what all the complexity is here, but I know it's not as
simple as the receive side where we already have the timestamp data when
filling in the receive descriptor.
I imagine if we used a completion model where Tx completions have their own
queue it wouldn't be as much of a problem. I don't know for sure though.
> > so if both
> > applications send a request at the same time one of them will
> > fail. They would need to either ensure they're off-sync or be
> > communicating to each other about when its ok to timestamp request
> > somehow.
>
> Oh, that will make the users of the new PHC vclock thing happy! I can
> already hear the complaints and bug reports here on our lists...
>
> Thanks,
> Richard
At least with ice we support up to 64 timestamps outstanding, so it's less of
an issue there....
Thanks,
Jake
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
