Re: 1.1.6 build fails on FC30
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 with NTP_PPS, which predates NO_HZ and never has been adapted for it. >> Once you have that working correctly you can try to enable hardpps, > > How? By switching off NO_HZ configuration (assuming you don't care about the other side effects that's going to have) and switching on NTP_PPS. You can then compare that with the performance of the previous kernel config and decide if its worth the trouble. My experience is that even without hardpps the clock can be controlled to much better precision than can be transferred even over LAN. > Yes, that makes the /dev/pps0 device appear. It also sends the PPS events to the kernel in your current configuration, which should recognizably change the clock rate. > We start ntpd after this step. …configured with or without flag3 set? > Sure, in the chroot (!) the devices (created with mknod) are owned by ntp: Then run the ppstest in the chroot also, perhaps? Anyway, I'd think the device should still be owned by root, but group ntp. If Fedora uses apparmor, you also need to add the device to the apparmor profile or ntpd will not be able to open it (check the audit log for errors). > If I run ntpd outside of the chroot the error does not appear and PPS > works. With or without the time going backwards? > So we take another look at the chroot... I'm not sure the chroot really buys you anything, security-wise. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
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. > CONFIG_PPS=y > # CONFIG_PPS_DEBUG is not set > # PPS clients support > # CONFIG_PPS_CLIENT_KTIMER is not set > CONFIG_PPS_CLIENT_LDISC=m > CONFIG_PPS_CLIENT_PARPORT=m > CONFIG_PPS_CLIENT_GPIO=m > # PPS generators support Except for the GPIO client that is what is in use here. > Once you have that working correctly you can try to enable hardpps, How? >> Yet we still see: >> REFCLOCK: refclock_ppsapi: time_pps_create: Operation not supported > > So does the PPS device exist and does it generate events? # ppstest /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 1572791560.772062581, sequence: 62 - clear 1572791559.972049895, sequence: 62 source 0 - assert 1572791560.772062581, sequence: 62 - clear 1572791560.972135103, sequence: 63 source 0 - assert 1572791561.772070058, sequence: 63 - clear 1572791560.972135103, sequence: 63 source 0 - assert 1572791561.772070058, sequence: 63 - clear 1572791561.972073160, sequence: 64 source 0 - assert 1572791562.772077047, sequence: 64 - clear 1572791561.972073160, sequence: 64 source 0 - assert 1572791562.772077047, sequence: 64 - clear 1572791562.972080079, sequence: 65 source 0 - assert 1572791563.772082569, sequence: 65 - clear 1572791562.972080079, sequence: 65 > If it's > coming in via a serial device, have you started an ldattach to enable > the PPS line discipline? Yes, that makes the /dev/pps0 device appear. We start ntpd after this step. If it is a link to the actual device (as usual > /dev/gpspps0 -> /dev/pps0), does it point to the correct device? Are > the permissions on the device correct? Sure, in the chroot (!) the devices (created with mknod) are owned by ntp: # ls -l /chroot/ntpd/dev/ total 0 lrwxrwxrwx 1 root root 5 Mar 9 2018 gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Mar 9 2018 gpspps0 -> pps0 srw-rw-rw- 1 root root 0 Nov 3 13:29 log crw-r--r-- 1 ntp ntp1, 3 Mar 9 2018 null crw-r--r-- 1 ntp ntp 252, 0 Mar 9 2018 pps0 crw-r--r-- 1 ntp ntp4, 64 Mar 9 2018 ttyS0 If I run ntpd outside of the chroot the error dopes not appear and PPS works. So we take another look at the chroot... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
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 was suggesting to start from a more standard kernel configuration, like so: CONFIG_NO_HZ_COMMON=y CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_PPS=y # CONFIG_PPS_DEBUG is not set # PPS clients support # CONFIG_PPS_CLIENT_KTIMER is not set CONFIG_PPS_CLIENT_LDISC=m CONFIG_PPS_CLIENT_PARPORT=m CONFIG_PPS_CLIENT_GPIO=m # PPS generators support Once you have that working correctly you can try to enable hardpps, but I suspect that it has bitrotted quite a bit except for the handful of embedded platforms where it is still the standard config. In other words, there may be new incompatibilities on your platform that nobody has yet encountered via interactions with other parts of the kernel (power management and the like). > Yet we still see: > REFCLOCK: refclock_ppsapi: time_pps_create: Operation not supported So does the PPS device exist and does it generate events? If it's coming in via a serial device, have you started an ldattach to enable the PPS line discipline? If it is a link to the actual device (as usual /dev/gpspps0 -> /dev/pps0), does it point to the correct device? Are the permissions on the device correct? lrwxrwxrwx 1 root root 5 Nov 3 12:59 /dev/gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Nov 3 12:59 /dev/gpspps0 -> pps0 crw-rw 1 root ntp 249, 0 Nov 3 12:59 /dev/pps0 Remember that running the PPS in via a serial line w/ PPS line discipline and having hardpps configured the kernel will take over the clock steering and NTP just needs to watch (which you need to tell it via flag3). The data you've shown indicates you run with hardpps _and_ try to steer the clock with ntpd as well. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
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_create: Operation not supported # gzip -dc /proc/config.gz |grep PPS CONFIG_PPS=y # CONFIG_PPS_DEBUG is not set CONFIG_NTP_PPS=y # PPS clients support CONFIG_PPS_CLIENT_KTIMER=m CONFIG_PPS_CLIENT_LDISC=y # CONFIG_PPS_CLIENT_PARPORT is not set # CONFIG_PPS_CLIENT_GPIO is not set # PPS generators support Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
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. Again, if you don#t actually use > hardpps (and if this is the same Ryzen system you've had the timer > trouble on) it would be much more likely to work if you didn't configure > NTP_PPS and left the timer selection at the automoatic choice TSC > instead of forcing HPET. We force hpet on the kernel commandline. >> We do run a 250HZ configuration. > > I'm pretty sure that hardpps was never thotoughly tested with HZ that Thanks for your thoughts. I will post the results... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
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 (via flag3) that the kernel PLL is > active. Otherwise, disable that option. We do have continuous timer ticks enabled. We do run a 250HZ configuration. # grep HZ .config CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
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, disable that option. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
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 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 have the baud rate correct? > > Yes. > `cat /dev/gps0` shows the NEMA stream. > >> What is in clockstats? > > We have clocklist: > > ntpq> clocklist > associd=0 status=0012 1 event, clk_bad_format, > name="NMEA", > timecode="$GPGGA,111253,5150.2223,N,00457.3970,E,1,08,1.0,-106.4,M,45.5,M,,*6F", > poll=14, noreply=0, badformat=1, baddata=0, fudgetime1=0.0, > fudgetime2=260.0, stratum=0, refid=GPS, flags=5, device="NMEA GPS Clock" > > > Then the 'badformat' is worrying. > What is wrong and how can I fix this? > > Also: when the GPS gives bad data, then why doesn't it use a different > clock as peer? We furthermore find: Nov 3 11:58:32 bv ntpd[15925]: REFCLOCK: refclock_ppsapi: time_pps_create: Operation not supported Nov 3 11:58:32 bv ntpd[15925]: REFCLOCK: NMEA(0) flag1 1 but PPSAPI fails yet: # grep PPS .config CONFIG_PPS=y # CONFIG_PPS_DEBUG is not set CONFIG_NTP_PPS=y # PPS clients support CONFIG_PPS_CLIENT_KTIMER=m CONFIG_PPS_CLIENT_LDISC=y # CONFIG_PPS_CLIENT_PARPORT is not set # CONFIG_PPS_CLIENT_GPIO is not set # PPS generators support # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
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 on. The 377 says it is working, but the > 0. and 0.0019 say that it isn't working. > > Do you have the baud rate correct? Yes. `cat /dev/gps0` shows the NEMA stream. > What is in clockstats? We have clocklist: ntpq> clocklist associd=0 status=0012 1 event, clk_bad_format, name="NMEA", timecode="$GPGGA,111253,5150.2223,N,00457.3970,E,1,08,1.0,-106.4,M,45.5,M,,*6F", poll=14, noreply=0, badformat=1, baddata=0, fudgetime1=0.0, fudgetime2=260.0, stratum=0, refid=GPS, flags=5, device="NMEA GPS Clock" Then the 'badformat' is worrying. What is wrong and how can I fix this? Also: when the GPS gives bad data, then why doesn't it use a different clock as peer? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
> 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 have the baud rate correct? What is in clockstats? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
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 >> === >> NMEA(0) .GPS.0 l 38 64 377 0. 0. >> 0.0019 (...) Similarly on another box: # ntpq -pn remote refid st t when poll reach delay offset jitter === NMEA(0) .GPS.0 l8 64 377 0. 0. 0.0019 fd00:c0a8:a00:1::70 67.96.200.2183 u 40 64 377 0.5053 -0.9482 0.1484 192.168.10.70 67.96.200.2183 u 55 64 377 0.3385 -0.9747 0.1622 2001:888:0:7::2 193.67.79.2022 u 55 64 377 14.5311 -3.6038 0.2071 2001:888:0:7::22193.67.79.2022 u 39 64 377 15.4898 -3.6090 0.2897 2001:888:0:8::42193.79.237.142 u 26 64 377 15.4917 -3.3595 0.3590 193.67.79.202 .GPS.1 u 35 64 377 18.2123 -3.4533 0.3782 193.79.237.14 .GPS.1 u 44 64 377 15.3530 -3.8482 0.0702 162.23.41.10.MRS.1 u 34 64 377 31.6796 -3.7795 0.1488 130.149.17.8.GPS.1 u 39 64 377 38.8027 -1.9196 0.3486 131.188.3.222 .MBGh. 1 u 19 64 377 27.3543 -2.3403 0.0917 131.188.3.223 .PZFs. 1 u 46 64 377 27.6289 -2.2454 0.2238 keetweej.vanheusden.com .DNS. 16 u- 1024 0 0. 0. 0.0019 185.31.230.94 .INIT. 16 u- 1024 0 0. 0. 0.0019 ntp.nmi.nl .DNS. 16 u- 1024 0 0. 0. 0.0019 134.221.205.12 .INIT. 16 u- 1024 0 0. 0. 0.0019 # ntptime ntp_gettime() returns code 0 (OK) time e1692e8d.fc7a5b10 2019-11-03T10:46:37.986Z, (.986242416), maximum error 2150516 us, estimated error 16 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency -30.043 ppm, interval 4 s, maximum error 2150516 us, estimated error 16 us, status 0x2001 (PLL,NANO), time constant 0, precision 1.000 us, tolerance 500 ppm, pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us, intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. We do see pps and nmea but ntpd does not choose the local gps. Why? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Determining the frequency offset
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. After a long expedition through the Linux kernel sources it turns out that the lowest level timestamping facility in the kernel already provides both the raw and real timer counts via ktime_get_snapshot, which means that it is in principle unnecessary to make multiple transitions to and from user space to get that data. The PPS subsystem does actually work with dual timestamps as well (although only internally, these get not exposed via the PPS API or sysfs). However, that facility is unfortunately tied to CONFIG_NTP_PPS (PPS kernel consumer / hardpps) which most modern systems never define because it is incompatible with a tickless kernel (hardpps never made the transition to periodic timer triggered vs. tick triggered). It seems worthwile to a) try and disentangle dual timestamps from hardpps in the kernel config, then b) provide userspace access to dual timestamps. Does anybody have experience with Linux kernel development and can comment on how one would get started? The necessary changes would be neatly confined to the PPS subsystem I think. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
