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: <166cb090-8dab-46a9-90a0-ff51553ef483@machnikowski.net>
Date: Wed, 14 Aug 2024 17:08:24 +0200
From: Maciek Machnikowski <maciek@...hnikowski.net>
To: Andrew Lunn <andrew@...n.ch>, Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: netdev@...r.kernel.org, richardcochran@...il.com,
 jacob.e.keller@...el.com, darinzon@...zon.com, kuba@...nel.org
Subject: Re: [RFC 0/3] ptp: Add esterror support



On 14/08/2024 15:08, Andrew Lunn wrote:
> On Wed, Aug 14, 2024 at 09:44:29AM +0100, Vadim Fedorenko wrote:
>> On 13/08/2024 21:05, Andrew Lunn wrote:
>>> On Tue, Aug 13, 2024 at 12:55:59PM +0000, Maciek Machnikowski wrote:
>>>> This patch series implements handling of timex esterror field
>>>> by ptp devices.
>>>>
>>>> Esterror field can be used to return or set the estimated error
>>>> of the clock. This is useful for devices containing a hardware
>>>> clock that is controlled and synchronized internally (such as
>>>> a time card) or when the synchronization is pushed to the embedded
>>>> CPU of a DPU.
>>>
>>> How can you set the estimated error of a clock? Isn't it a properties
>>> of the hardware, and maybe the network link? A 10BaseT/Half duplex
>>> link is going to have a bigger error than a 1000BaseT link because the
>>> bits take longer on the wire etc.
>>
>> AFAIU, it's in the spec of the hardware, but it can change depending on
>> the environment, like temperature. The link speed doesn't matter here,
>> this property can be used to calculate possible drift of the clock in
>> the micro holdover mode (between sync points).
> 
> Is there a clear definition then? Could you reference a standard
> indicating what is included and excluded from this?
> 
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


>>> What is the device supposed to do with the set value?
>>
>> It can be used to report the value back to user-space to calculate the
>> boundaries of "true time" returned by the hardware.
> 
> So the driver itself does not know its own error? It has to be told
> it, so it can report it back to user space. Then why bother, just put
> it directly into the ptp4l configuration file?
> 
> Maybe this is all obvious to somebody who knows PTP inside out, but to
> me it is not. Please could you put a better explanation and
> justification into the commit message. We need PHY driver writers who
> have limited idea about PTP can implement these new calls.
>
> Andrew

It's designed to enable devices that either synchronize its own hw clock
to some source of time on a hardware layer (e.g. a Timecard that uses a
PPS signal from the GNSS), or a device in which the PTP is done on a
different function (multifunction NIC, or a DPU) to convey its best
estimate of the error (see above). In case of a multifunction NIC the
ptp daemon running on a function that synchronizes the clock will use
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
b. prevent time-dependent functionalities from acting when a clock
shifts beyond a predefined limit.

Also esterror is not maxerror and is not designed to include all errors,
but the best estimate

Thanks
Maciek