netdev - 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: <fea51ae9423c07e674402047851dd712ff1733bb.camel@oss.nxp.com>
Date:   Thu, 07 Oct 2021 15:31:43 +0200
From:   Sebastien Laveze <sebastien.laveze@....nxp.com>
To:     Richard Cochran <richardcochran@...il.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 Thu, 2021-09-30 at 07:35 -0700, Richard Cochran wrote:
> > What we miss currently in the kernel for a better multi-domain usage
> > and would like to find a solution:
> > -allow PHC adjustment with virtual clocks. Otherwise scheduled traffic
> > cannot be used... (I've read your comments on this topic, we are
> > experimenting things on MCUs and we need to assess on measurements)
> 
> Yeah, so you cannot have it both ways, I'm afraid.  Either you adjust
> the HW clock or not.  If you don't, it becomes impractical to program
> the event registers for output signals.  (Time stamps on input signals
> are not an issue, though)

Yes, this is especially true for periodic events completely handled in
hardware like scheduled traffic.

However, not being able to support multiple domains + scheduled traffic
is a true limitation for TSN use cases.

I'm aware of your opinon on this topic:
https://lore.kernel.org/netdev/20210510231832.GA28585@hoboy.vegasvil.org/

However, a few points that _might_ change your mind:
* regular and random small adjustments don't cost that much since the
error you create for the children clocks is only the time for the PHC
to adjust. Since this time is quite small (~10 us ? ), a few ppm on
this short time is negligible.

For example:
Let's take a worst case, the PHC is adjusted every 10 ms, vclock every
1 sec with 1 ppm error.
vclock error is 1 us, now if you add the 100 PHC adjustments each of
them with an error of 1 ppm over 10 us. That gives 0.01 ns * 100 = 1
ns.
This is negligible vs the 1 us error.
Of course, in general, the vclock would be updated more frequently but
in this case even less impacted by PHC adjustments.

* large frequency adjustments are more problematic. I've checked that
some drivers allow up to 10^6 ppm... 
This could lead to non-negligible error. However, since it's already
accepted that using vclock is at the cost of loosing adjustments on the
PHC, it could be accepted that it's still adjustable but with some
restrictions. (1000 ppm max ?)

* offset adjustments do not introduce any error if performed in
software. On other systems we support, handling the offset in software
helped to improve stability as the hardware time becomes monotonic.
There is no added value in setting the offset in the PHC.

> I think the best option for user space wanting timers in multiple
> domains is to periodically do 
> 
>    gettime(monotonic); gettime(vclock); gettime(monotonic);
> 
> figure the conversion, and schedule using clock_monotonic.

Yes, having a good ratio/offset measurement should lead to decent
performance.

Thanks,
Sebastien