[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1ed179d2-cedc-40d3-95ea-70c80ef25d91@machnikowski.net>
Date: Thu, 15 Aug 2024 11:40:28 +0200
From: Maciek Machnikowski <maciek@...hnikowski.net>
To: Richard Cochran <richardcochran@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, 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 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
>
>> the ADJ_ESTERROR to push the error estimate to the device. The device
>> will then be able to
>> a. provide that information to hardware clocks on different functions
>
> Not really, because there no in-kernel API for one device to query
> another. At least you didn't provide one. Looks like you mean that
> some user space program sets the value, and another program reads it
> to share it with other devices?
>
>> b. prevent time-dependent functionalities from acting when a clock
>> shifts beyond a predefined limit.
>
> This can be controlled by the user space stack. For example, "if
> estimated error exceeds threshold, disable PPS output".
>
> Thanks,
> Richard
It's doable if everything runs on the same OS, but there are cases where
time sync is part of management and we will want to disable features on
different PFs/VFs as a result of bad time synchronizations. Such
features include launchtime or time-based congestion control which are
part of infrastructure.
Powered by blists - more mailing lists