On 12-04-2020 14:55, ASSI via devel wrote: > Udo van den Heuvel via devel writes: >> Using tsc clocksource we get: >> >> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource >> tsc >> # ntpq -pn >> remote refid st t when poll reach delay offset >> jitter >> =============================================================================== >> +NMEA(0) .GPS. 0 l 9 64 377 0.0000 0.0000 >> 0.0019 >> *192.168.10.98 .GPS. 1 u 27 64 377 0.3096 -0.0919 >> 0.1178 >> +fd00:c0a8:a00:1 .GPS. 1 u 37 64 377 0.3211 -0.0505 >> 0.0775 >> >> I.e.: no system peer selection of GPS. >> We tried HPET, AC PI_PM and now TSC. >> None of them works to fix this issue. > > Then the clock isn't really the problem I suppose. The GPS is reachable > and has no offset and low jitter, but doesn't appear to use PPS;
When then is the jitter so low? If solely using NMEA the jitter and offset would be worse. But: should ttyS0 show up in /proc/interrups? (ttyS1 does) Both are on a single pciE card. Setserial shows: # /bin/setserial /dev/ttyS0 /dev/ttyS0, UART: 16850, Port: 0xd0c0, IRQ: 37, Flags: low_latency # /bin/setserial /dev/ttyS1 /dev/ttyS1, UART: 16850, Port: 0xd0c8, IRQ: 37 # cat /dev/gps0 (NMEA stream) > although from your boot log it's clear you were apparently expecting to > use that. Have you set the flag to use the PPS and does the device > deliver (stable) PPS signal? # ppswatch /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" timestamp: 1586697390, sequence: 139, offset: 199075943 timestamp: 1586698062, sequence: 140, offset: 196910388 timestamp: 1586698062, sequence: 140, offset: 196910388 timestamp: 1586698063, sequence: 141, offset: 196889843 timestamp: 1586698063, sequence: 141, offset: 196889843 timestamp: 1586698064, sequence: 142, offset: 196873213 timestamp: 1586698064, sequence: 142, offset: 196873213 timestamp: 1586698065, sequence: 143, offset: 196852628 timestamp: 1586698065, sequence: 143, offset: 196852628 timestamp: 1586698066, sequence: 144, offset: 196834846 timestamp: 1586698066, sequence: 144, offset: 196834846 timestamp: 1586698067, sequence: 145, offset: 196818850 timestamp: 1586698067, sequence: 145, offset: 196818850 timestamp: 1586698068, sequence: 146, offset: 196800678 timestamp: 1586698068, sequence: 146, offset: 196800678 timestamp: 1586698069, sequence: 147, offset: 196782262 timestamp: 1586698069, sequence: 147, offset: 196782262 timestamp: 1586698070, sequence: 148, offset: 196762613 # ppswatch /chroot/ntpd/dev/pps0 (shows similar output) Something is coming out of it. > If so, does the device file expected by > ntpd exist in your chroot environment (generally a symlink to the real > /dev/pps* device) and is it readable by ntpd? # ls -l /dev/*ps* lrwxrwxrwx 1 root root 5 Apr 12 11:58 /dev/gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Apr 12 11:58 /dev/gpspps0 -> pps0 crw-rw---- 1 root ntp 253, 0 Apr 12 11:58 /dev/pps0 # ls -l /chroot/ntpd/dev/*ps* lrwxrwxrwx 1 root root 5 Mar 9 2018 /chroot/ntpd/dev/gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Mar 9 2018 /chroot/ntpd/dev/gpspps0 -> pps0 crw-r--r-- 1 ntp ntp 253, 0 Nov 3 17:15 /chroot/ntpd/dev/pps0 > Also, if there's an > apparmor profile for ntpd, check in /var/log/audit/audit.log (or > wherever that is under Fedora, also in the chroot maybe) that apparmor > allows the access as well. selinux is disabled. never used apparmor. Udo _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel