linux-kernel - Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210928133100.GB28632@hoboy.vegasvil.org>
Date:   Tue, 28 Sep 2021 06:31:00 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     Sebastien Laveze <sebastien.laveze@....nxp.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        yangbo.lu@....com, yannick.vignon@....nxp.com,
        rui.sousa@....nxp.com
Subject: Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL

On Tue, Sep 28, 2021 at 01:50:23PM +0200, Sebastien Laveze wrote:
> Yes that would do it. Only drawback is that ALL rx and tx timestamps
> are converted to the N domains instead of a few as needed.

No, the kernel would provide only those that are selected by the
program via the socket option API.

> Before going in this direction, is this a change that you really see as
> worthwile for virtual clocks and timetamping support ?

Yes, indeed.

> What approach do you have in mind for multi-domain support with the
> common CMLDS layer ?

Okay, so I briefly reviewed IEEE Std 802.1AS-2020 Clause 11.2.17.

I think what it boils down to is this:  (please correct me if I'm wrong)

When running PTP over multiple domains on one port, the P2P delay
needs only to be measured in one domain.  It would be wasteful to
measure the peer delay in multiple parallel domains.

linuxptp already provides PORT_DATA_SET.peerMeanPathDelay via management.
The only things missing AFAICT are:

1. neighborRateRatio - This can be provided via a new custom
   management message.

2. Inhibiting the delay mechanism as a per-port option.

All you need to implement CMLDS correction is:

1. nRR from one port, read by other ports via management.

2. periodic clock_gettime() on both ports to figure the rate
   difference between the two ports.

Having said that, because the NR differences will be tiny, and the p2p
message delay so short (like 100 nanoseconds or less), it is
practically worthless to apply the correction.  I personally wouldn't
bother, unless you can prove by measurement that the correction makes
a difference in the synchronization quality.

Thanks,
Richard