From: Vladimir Oltean <olteanv@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Saeed Mahameed <saeed@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, Eran Ben Elisha <eranbe@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>,
Richard Cochran <richardcochran@gmail.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Subject: Re: [net-next V2 08/15] net/mlx5e: Add TX PTP port object support
Date: Sat, 5 Dec 2020 03:49:27 +0200 [thread overview]
Message-ID: <20201205014927.bna4nib4jelwkxe7@skbuf> (raw)
In-Reply-To: <20201204122613.542c2362@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
On Fri, Dec 04, 2020 at 12:26:13PM -0800, Jakub Kicinski wrote:
> On Fri, 04 Dec 2020 11:33:26 -0800 Saeed Mahameed wrote:
> > On Thu, 2020-12-03 at 18:29 -0800, Jakub Kicinski wrote:
> > > On Wed, 2 Dec 2020 20:21:01 -0800 Saeed Mahameed wrote:
> > > > Add TX PTP port object support for better TX timestamping accuracy.
> > > > Currently, driver supports CQE based TX port timestamp. Device
> > > > also offers TX port timestamp, which has less jitter and better
> > > > reflects the actual time of a packet's transmit.
> > >
> > > How much better is it?
> > >
> > > Is the new implementation is standard compliant or just a "better
> > > guess"?
> >
> > It is not a guess for sure, the closer to the output port you take the
> > stamp the more accurate you get, this is why we need the HW timestamp
> > in first place, i don't have the exact number though, but we target to
> > be compliant with G.8273.2 class C, (30 nsec), and this code allow
> > Linux systems to be deployed in the 5G telco edge. Where this standard
> > is needed.
>
> I see. IIRC there was also an IEEE standard which specified the exact
> time stamping point (i.e. SFD crosses layer X). If it's class C that
> answers the question, I think.
The ITU-T G.8273.2 specification just requires a Class C clock to have a
maximum absolute time error under steady state of 30 ns. And taking
timestamps closer to the wire eliminates some clock domain crossings
from what is measured in the path delay, this is probably the reason why
timestamping is more accurate, and it helps to achieve the required
jitter figure.
The IEEE standard that you're thinking of is clause "7.3.4 Generation of
event message timestamps" of IEEE 1588.
-----------------------------[cut here]-----------------------------
7.3.4.1 Event message timestamp point
Unless otherwise specified in a transport-specific annex to this
standard, the message timestamp point for an event message shall be the
beginning of the first symbol after the Start of Frame (SOF) delimiter.
7.3.4.2 Event timestamp generation
All PTP event messages are timestamped on egress and ingress. The
timestamp shall be the time at which the event message timestamp point
passes the reference plane marking the boundary between the PTP node and
the network.
NOTE 1— If an implementation generates event message timestamps using a
point other than the message timestamp point, then the generated
timestamps should be appropriately corrected by the time interval
between the actual time of detection and the time the message timestamp
point passed the reference plane. Failure to make these corrections
results in a time offset between the slave and master clocks.
-----------------------------[cut here]-----------------------------
So there you go, it just says "the reference plane marking the boundary
between the PTP node and the network". So it depends on how you draw the
borders. I cannot seem to find any more precise definition.
Regardless of the layer at which the timestamp is taken, it is the
jitter that matters more than the reduced path delay. The latter is just
a side effect.
"How much better" is an interesting question though.
next prev parent reply other threads:[~2020-12-05 1:50 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 4:20 [pull request][net-next V2 00/15] mlx5 updates 2020-12-01 Saeed Mahameed
2020-12-03 4:20 ` [net-next V2 01/15] net/mlx5e: Free drop RQ in a dedicated function Saeed Mahameed
2020-12-03 4:20 ` [net-next V2 02/15] net/mlx5e: Allow CQ outside of channel context Saeed Mahameed
2020-12-03 4:20 ` [net-next V2 03/15] net/mlx5e: Allow RQ " Saeed Mahameed
2020-12-03 4:20 ` [net-next V2 04/15] net/mlx5e: Allow SQ " Saeed Mahameed
2020-12-03 4:20 ` [net-next V2 05/15] net/mlx5e: Change skb fifo push/pop API to be used without SQ Saeed Mahameed
2020-12-03 4:20 ` [net-next V2 06/15] net/mlx5e: Split SW group counters update function Saeed Mahameed
2020-12-03 4:21 ` [net-next V2 07/15] net/mlx5e: Move MLX5E_RX_ERR_CQE macro Saeed Mahameed
2020-12-03 4:21 ` [net-next V2 08/15] net/mlx5e: Add TX PTP port object support Saeed Mahameed
2020-12-04 2:29 ` Jakub Kicinski
2020-12-04 19:33 ` Saeed Mahameed
2020-12-04 20:26 ` Jakub Kicinski
2020-12-04 21:57 ` Saeed Mahameed
2020-12-04 22:52 ` Jakub Kicinski
2020-12-05 0:55 ` Vladimir Oltean
2020-12-07 6:22 ` Saeed Mahameed
2020-12-04 23:17 ` Jakub Kicinski
2020-12-04 23:57 ` Saeed Mahameed
2020-12-05 0:24 ` Jakub Kicinski
2020-12-06 13:37 ` Eran Ben Elisha
2020-12-06 17:08 ` Richard Cochran
2020-12-07 8:37 ` Saeed Mahameed
2020-12-07 11:05 ` Eran Ben Elisha
2020-12-07 15:19 ` Richard Cochran
2020-12-07 20:42 ` Jakub Kicinski
2020-12-07 22:04 ` Saeed Mahameed
2020-12-08 13:02 ` Richard Cochran
2020-12-06 13:36 ` Eran Ben Elisha
2020-12-07 20:29 ` Jakub Kicinski
2020-12-06 13:33 ` Eran Ben Elisha
2020-12-05 1:49 ` Vladimir Oltean [this message]
2020-12-05 2:10 ` Jakub Kicinski
2020-12-05 13:20 ` Richard Cochran
2020-12-07 5:50 ` Saeed Mahameed
2020-12-03 4:21 ` [net-next V2 09/15] net/mlx5e: Add TX port timestamp support Saeed Mahameed
2020-12-03 4:21 ` [net-next V2 10/15] net/mlx5e: remove unnecessary memset Saeed Mahameed
2020-12-03 4:21 ` [net-next V2 11/15] net/mlx5e: Remove duplicated include Saeed Mahameed
2020-12-03 4:21 ` [net-next V2 12/15] net/mlx5: Arm only EQs with EQEs Saeed Mahameed
2020-12-03 4:21 ` [net-next V2 13/15] net/mlx5: Fix passing zero to 'PTR_ERR' Saeed Mahameed
2020-12-03 4:21 ` [net-next V2 14/15] net/mlx5e: Split between RX/TX tunnel FW support indication Saeed Mahameed
2020-12-03 4:21 ` [net-next V2 15/15] net/mlx5e: Fill mlx5e_create_cq_param in a function Saeed Mahameed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201205014927.bna4nib4jelwkxe7@skbuf \
--to=olteanv@gmail.com \
--cc=davem@davemloft.net \
--cc=eranbe@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--cc=saeed@kernel.org \
--cc=tariqt@nvidia.com \
--cc=vladimir.oltean@nxp.com \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).