linuxptp-users

[Linuxptp-users] Overflow issue for 32bit machines: ptp_clock_info.max_adj versus timex.freq

[Janusz U. <j.u...@el...>]

Hi.

A lot of PTP/PHC drivers set max_adj value quite big. Howover due to 
kernel's API limit of 32bit long type value (freq) and POSIX frequency 
conversion it should limited to 32767999 ppb.

It concerns the frequency limit check both for kernel, testptp and 
ptp4linux servos. Simply 65.536 * 32767999 is almost 2^31... It is also 
common for adjfreq() vs newer adjfine().
Moreover such big frequency limits seem not practical (phase jump used 
instead, 1000ppm is huge for any PTP oscillator application), even 
driver or rather PHC hardware has ability to tune is such range.


best regards
Janusz Uzycki

Re: [Linuxptp-users] Overflow issue for 32bit machines: ptp_clock_info.max_adj versus timex.freq

[Janusz U. <j.u...@el...>]

More details:
The type of "freq" field in "__kernel_timex" structure is fixed in 
mainline kernel to "long long" type.
However "__kernel_long_t freq" in timex structure depends on machine.
Eg. for some machines it see:
include/uapi/asm-generic/posix_types.h:typedef long __kernel_long_t;
arch/sparc/include/uapi/asm/posix_types.h: typedef long __kernel_long_t;

best regards
Janusz Uzycki


W dniu 06/10/2022 o 00:11, Janusz Użycki pisze:
> Hi.
>
> A lot of PTP/PHC drivers set max_adj value quite big. Howover due to 
> kernel's API limit of 32bit long type value (freq) and POSIX frequency 
> conversion it should limited to 32767999 ppb.
>
> It concerns the frequency limit check both for kernel, testptp and 
> ptp4linux servos. Simply 65.536 * 32767999 is almost 2^31... It is 
> also common for adjfreq() vs newer adjfine().
> Moreover such big frequency limits seem not practical (phase jump used 
> instead, 1000ppm is huge for any PTP oscillator application), even 
> driver or rather PHC hardware has ability to tune is such range.
>
>
> best regards
> Janusz Uzycki
>
>

Re: [Linuxptp-users] Overflow issue for 32bit machines: ptp_clock_info.max_adj versus timex.freq

[Miroslav L. <mli...@re...>]

On Thu, Oct 06, 2022 at 12:11:39AM +0200, Janusz Użycki wrote:
> Hi.
> 
> A lot of PTP/PHC drivers set max_adj value quite big. Howover due to
> kernel's API limit of 32bit long type value (freq) and POSIX frequency
> conversion it should limited to 32767999 ppb.
> 
> It concerns the frequency limit check both for kernel, testptp and ptp4linux
> servos. Simply 65.536 * 32767999 is almost 2^31... It is also common for
> adjfreq() vs newer adjfine().
> Moreover such big frequency limits seem not practical (phase jump used
> instead, 1000ppm is huge for any PTP oscillator application), even driver or
> rather PHC hardware has ability to tune is such range.

What issue are you seeing with linuxptp?

In phc_max_adj() there is some code clamping the value on 32-bit
systems, so the overflow should be avoided.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Overflow issue for 32bit machines: ptp_clock_info.max_adj versus timex.freq

[Janusz U. <j.u...@el...>]

> On Thu, Oct 06, 2022 at 12:11:39AM +0200, Janusz Użycki wrote:
>> Hi.
>>
>> A lot of PTP/PHC drivers set max_adj value quite big. Howover due to
>> kernel's API limit of 32bit long type value (freq) and POSIX frequency
>> conversion it should limited to 32767999 ppb.
>>
>> It concerns the frequency limit check both for kernel, testptp and ptp4linux
>> servos. Simply 65.536 * 32767999 is almost 2^31... It is also common for
>> adjfreq() vs newer adjfine().
>> Moreover such big frequency limits seem not practical (phase jump used
>> instead, 1000ppm is huge for any PTP oscillator application), even driver or
>> rather PHC hardware has ability to tune is such range.
> What issue are you seeing with linuxptp?
>
> In phc_max_adj() there is some code clamping the value on 32-bit
> systems, so the overflow should be avoided.

When I set testptp -f 32768000 or more PHC time starts to drift in 
opposite direction relative to synced REALTIME system clock, tested 
using testptp -k1.
First I noted the issue on much older kernel than latest mainline.


best regrds
Janusz

Re: [Linuxptp-users] Overflow issue for 32bit machines: ptp_clock_info.max_adj versus timex.freq

[Janusz U. <j.u...@el...>]

OK. The issue is not related to linuxptp v3.1. Thank you for pointing 
the clamp.
Is it common for phc2sys and ts2phc also ?

best regards
Janusz



W dniu 06/10/2022 o 09:19, Janusz Użycki pisze:
>
>> On Thu, Oct 06, 2022 at 12:11:39AM +0200, Janusz Użycki wrote:
>>> Hi.
>>>
>>> A lot of PTP/PHC drivers set max_adj value quite big. Howover due to
>>> kernel's API limit of 32bit long type value (freq) and POSIX frequency
>>> conversion it should limited to 32767999 ppb.
>>>
>>> It concerns the frequency limit check both for kernel, testptp and 
>>> ptp4linux
>>> servos. Simply 65.536 * 32767999 is almost 2^31... It is also common 
>>> for
>>> adjfreq() vs newer adjfine().
>>> Moreover such big frequency limits seem not practical (phase jump used
>>> instead, 1000ppm is huge for any PTP oscillator application), even 
>>> driver or
>>> rather PHC hardware has ability to tune is such range.
>> What issue are you seeing with linuxptp?
>>
>> In phc_max_adj() there is some code clamping the value on 32-bit
>> systems, so the overflow should be avoided.
>
> When I set testptp -f 32768000 or more PHC time starts to drift in 
> opposite direction relative to synced REALTIME system clock, tested 
> using testptp -k1.
> First I noted the issue on much older kernel than latest mainline.
>
>
> best regrds
> Janusz
>
>
>
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] Overflow issue for 32bit machines: ptp_clock_info.max_adj versus timex.freq

[Miroslav L. <mli...@re...>]

On Thu, Oct 06, 2022 at 09:23:57AM +0200, Janusz Użycki wrote:
> OK. The issue is not related to linuxptp v3.1. Thank you for pointing the
> clamp.
> Is it common for phc2sys and ts2phc also ?

I see a phc_max_adj() call in both phc2sys and ts2phc, so I'd expect
them to handle it correctly.

-- 
Miroslav Lichvar