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