netdev - Re: [RFC 0/3] ptp: Add esterror support

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: <e148e28d-e0d2-4465-962d-7b09a7477910@machnikowski.net>
Date: Thu, 15 Aug 2024 17:00:24 +0200
From: Maciek Machnikowski <maciek@...hnikowski.net>
To: Andrew Lunn <andrew@...n.ch>
Cc: Richard Cochran <richardcochran@...il.com>,
 Vadim Fedorenko <vadim.fedorenko@...ux.dev>, netdev@...r.kernel.org,
 jacob.e.keller@...el.com, darinzon@...zon.com, kuba@...nel.org
Subject: Re: [RFC 0/3] ptp: Add esterror support



On 15/08/2024 16:26, Andrew Lunn wrote:
> On Thu, Aug 15, 2024 at 11:40:28AM +0200, Maciek Machnikowski wrote:
>>
>>
>> On 15/08/2024 05:53, Richard Cochran wrote:
>>> On Wed, Aug 14, 2024 at 05:08:24PM +0200, Maciek Machnikowski wrote:
>>>
>>>> The esterror should return the error calculated by the device. There is
>>>> no standard defining this, but the simplest implementation can put the
>>>> offset calculated by the ptp daemon, or the offset to the nearest PPS in
>>>> cases where PPS is used as a source of time
>>>
>>> So user space produces the number, and other user space consumes it?
>>>
>>> Sounds like it should say in user space, shared over some IPC, like
>>> PTP management messages for example.
>>
>> The user spaces may run on completely isolated platforms in isolated
>> network with no direct path to communicate that.
>> I'm well aware of different solutions on the same platform (libpmc, AWS
>> Nitro or Clock Manager) , but this patchset tries to address different
>> use case
> 
> So this in effect is just a communication mechanism between two user
> space processes. The device itself does not know its own error, and
> when told about its error, it does nothing. So why add new driver API
> calls? It seems like the core should be able to handle this. You then
> don't need a details explanation of the API which a PHY driver writer
> can understand...
> 
>        Andrew

No - it is not the main use case. The easiest one to understand would be
the following:

Think about a Time Card
(https://opencomputeproject.github.io/Time-Appliance-Project/docs/time-card/introduction).

It is a device that exposes the precise time to the user space using the
PTP subsystem, but it is an autonomous device and the synchronization is
implemented on the hardware layer.
In this case no user space process is now aware of what is the expected
estimated error, because that is only known to the HW and its control loop.
And this information is needed for the aforementioned userspace
processes to calculate error boundaries (time uncertaninty) of a given
clock.

-Maciek