Udo van den Heuvel via devel writes:
> We found out that the major number of the pps0 device had changed.
You shouldn't assume fixed device numbers for devices generated
dynamically. Look in /proc/devices instead of hardcoding the major
number. Alternatively, sysfs lets you know the device numbe
On 03-11-2019 17:12, Achim Gratz via devel wrote:
>> So we take another look at the chroot...
>
> I'm not sure the chroot really buys you anything, security-wise.
Not doing anything felt not OK.
ntpd run outside of the chroot does not have an issue.
ntpd in the chroot does have this issue.
We f
Udo van den Heuvel via devel writes:
> I do not understand why NO_HZ is necessary or even usable without
> conflict witgh PPS such as CONFIG_NO_HZ_COMMON.
NO_HZ has been the default configuration for a long time and it doesn't
have anything to do with the PPS API support. The _only_ conflict is
w
On 03-11-2019 14:36, Achim Gratz via devel wrote:
> configuration, like so:
>
> CONFIG_NO_HZ_COMMON=y
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
I do not understand why NO_HZ is necessary or even usable without
conflict witgh PPS such as CONFIG_NO_HZ_COMMON.
> CONFI
Udo van den Heuvel via devel writes:
> On 03-11-2019 13:22, Udo van den Heuvel via devel wrote:
>> Thanks for your thoughts. I will post the results...
>
> # gzip -dc /proc/config.gz |grep NO_HZ
> # CONFIG_NO_HZ_IDLE is not set
> # CONFIG_NO_HZ_FULL is not set
> # CONFIG_NO_HZ is not set
Again, I
On 03-11-2019 13:22, Udo van den Heuvel via devel wrote:
> Thanks for your thoughts. I will post the results...
# gzip -dc /proc/config.gz |grep NO_HZ
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
Yet we still see:
REFCLOCK: refclock_ppsapi: time_pps_crea
On 03-11-2019 13:10, Achim Gratz via devel wrote:
>> We do have continuous timer ticks enabled.
>
> That doesn't matter AFAIK. The incompatibility is already introduced by
>
> CONFIG_NO_HZ_COMMON=y
Ah This box has that setting.
The other does not.
> based on the comments in the source. Ag
Udo van den Heuvel via devel writes:
> On 03-11-2019 12:35, ASSI via devel wrote:
>> Udo van den Heuvel via devel writes:
>>> yet:
>>>
>>> # grep PPS .config
>>> CONFIG_PPS=y
>>> # CONFIG_PPS_DEBUG is not set
>>> CONFIG_NTP_PPS=y
>>
>> If you really wanted to enable hardpps, then you _must_ disabl
On 03-11-2019 12:35, ASSI via devel wrote:
> Udo van den Heuvel via devel writes:
>> yet:
>>
>> # grep PPS .config
>> CONFIG_PPS=y
>> # CONFIG_PPS_DEBUG is not set
>> CONFIG_NTP_PPS=y
>
> If you really wanted to enable hardpps, then you _must_ disable NOHZ in
> the kernel config and let ntpd know
Udo van den Heuvel via devel writes:
> yet:
>
> # grep PPS .config
> CONFIG_PPS=y
> # CONFIG_PPS_DEBUG is not set
> CONFIG_NTP_PPS=y
If you really wanted to enable hardpps, then you _must_ disable NOHZ in
the kernel config and let ntpd know (via flag3) that the kernel PLL is
active. Otherwise, di
On 03-11-2019 12:15, Udo van den Heuvel via devel wrote:
>
> On 03-11-2019 12:06, Hal Murray wrote:
>>
>>> We do see pps and nmea but ntpd does not choose the local gps. Why?
>>
>> How do you "see" them?
>
> I use `ntpq -pn` to see what the status is.
>
>
>>> NMEA(0) .GPS.0 l8 64
On 03-11-2019 12:06, Hal Murray wrote:
>
>> We do see pps and nmea but ntpd does not choose the local gps. Why?
>
> How do you "see" them?
I use `ntpq -pn` to see what the status is.
>> NMEA(0) .GPS.0 l8 64 377 0. 0. 0.0019
>
> I don't understand what's going o
> We do see pps and nmea but ntpd does not choose the local gps. Why?
How do you "see" them?
> NMEA(0) .GPS.0 l8 64 377 0. 0. 0.0019
I don't understand what's going on. The 377 says it is working, but the
0. and 0.0019 say that it isn't working.
Do you hav
On 02-08-2019 10:31, Udo van den Heuvel via devel wrote:
> On 02-08-19 07:33, Udo van den Heuvel via devel wrote:
>> On one machine I see something weird:
>>
>> # ntpq -pn
>> remote refid st t when poll reach delay offset
>> jitter
>> ===
Achim Gratz via devel writes:
> I have been experimenting with determining the frequency offset via the
> MONOTONIC_RAW clock. At the moment I've implemented that as a Perl
> script although it should eventually go into some sort of pps-raw device
> driver that timestamps the incoming PPS pulses.
15 matches
Mail list logo
