FS#46887 - [ntp] upstream seems to have disabled ATOM clock type driver

Attached to Project: Arch Linux
Opened by Peter Dohm (N3rdle) - Tuesday, 27 October 2015, 16:50 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:24 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

Upstream appears to no longer include the ATOM clock type PPS driver for NTP by default. There are many people who depend upon this clock type to make accurate GPS disciplined clocks using the PPS support in NTPD. This was previously working perfectly.

Additional info:
* ntp package version 4.2.8.p4-1
* config - include the following snippet
-------------
# the ATOM PPS driver
server 127.127.22.0 minpoll 3 maxpoll 3
fudge 127.127.22.0 refid PPS
-------------

Steps to reproduce:

include the snippet of the config as pasted above. you will get the following error in logs:

refclock_newpeer: clock type 22 invalid

Proposed Mitigation:

i believe that we simply need to add --enable-ATOM to the configure command line
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:24 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/ntp/issues/1
Comment by Evangelos Foutras (foutrelis) - Wednesday, 28 October 2015, 05:57 GMT
> This was previously working perfectly.

When you say "previously", what's the rough time frame? I tested ntp-4.2.6.p5-17 (~ Aug 1st 2013) and it outputs the same error.

The --enable-ATOM option is enabled by default, but the problem seems to be the absence of the timepps.h header (part of pps-tools).
Comment by Peter Dohm (N3rdle) - Wednesday, 28 October 2015, 12:38 GMT
this was working correctly in the previously packaged release for arm, i believe.

i took the most recent build files for x86/x86_64 and simply added the arm platform identifier and forcibly enabled atom; everything worked perfectly when built directly on an arm, so hopefully this helps you pinpoint the exact issue...
Comment by Bret Towe (magnade) - Sunday, 13 August 2017, 22:47 GMT
I just grabbed the ntp build scripts made no modifications but did have on that system pps-tools installed
and its using pps now
so from what I see having pps-tools part of arch and then adding as build dep for ntp is all thats required
Comment by Bret Towe (magnade) - Thursday, 15 August 2019, 03:12 GMT
so 2 years later I can confirm this is still all that is needed.
pps-tools was install so not added to deps

@@ -28,7 +28,7 @@
build() {
cd "${srcdir}/${_pkgname}-${_pkgver}"

- ./configure --prefix=/usr --libexecdir=/usr/lib --enable-linuxcaps --enable-ntp-signd
+ ./configure --prefix=/usr --libexecdir=/usr/lib --enable-linuxcaps --enable-ntp-signd --enable-ATOM
make
}
Comment by loqs (loqs) - Tuesday, 08 September 2020, 00:59 GMT
I can not reproduce a change by adding --enable-ATOM, the change is produced by the presence or absence of the AUR package pps-tools as concluded by foutrelis.
Comment by Bret Towe (magnade) - Saturday, 09 January 2021, 00:53 GMT
is there any reason why pps-tools isn't just imported into main tree?
it doesn't look like it changes much so maintenance cost is low
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.
Comment by Toolybird (Toolybird) - Wednesday, 20 September 2023, 02:30 GMT
pps-tools was added to the main repos Feb 2021, so in theory this could now be implemented.

Loading...