Description of problem: On F7 ntp can not work 1PPS together with gpsd. On FC6 and stock kernel, with the serial DCD line connected to a GPS receiver with 1PPS support, ntpq -p happy reported that * (primary) was from SHM(1) .GPS1. and + (secondary) was from SHM(0) .GPS. However since upgrading to F7 it refuses to work 1PPS, it only locks * (primary) from SHM(0) .GPS. There is too much gitter without 1PPS for precise time server use and it needs to be fixed. I filled bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242211 but told its not the kernel and the bug is still there and no one is fixing the issue. As gpsd is the same source for F7 as was with FC6, the problem has to be ntp. Version-Release number of selected component (if applicable): How reproducible: 1PPS worked with FC6 and now does not with F7, hardware is the same, config files everything. Steps to Reproduce: 1. 2. 3. Actual results: No 1PPS support Expected results: 1PPS support Additional info:
Does ntpd from the FC-6 package have the same problem?
Thanks for the reply. No on FC6 no issue at all, ntpd happily uses the 1PPS output from gpsd. Its one of three things in F7, kernel, ntpd or gpsd. Its the same computer and config files for gpsd and ntp, so hardware has not changed, just its gone from FC6 to F7. I naturally had to set selinux to permissive until my other bug of needing a ntpd policy added to selinux on F7, so you can run enforcing, but ntpd will sync to gpsd. Anything else you need?
Yes. I'm not sure if you have already tried, but I need to know if FC-6 ntp is ok on F-7. Please downgrade ntp to FC-6 (ntp-4.2.4p0-1.fc6) and see if it's better. If it works ok, it's a problem in ntp.
no problems can do, how do I downgrade ntp to fc6 and then back to f7? I downloaded the rpms...
downgrade: rpm -U --oldpackage ntp-4.2.4p0-1.fc6.i386.rpm and back to F-7 ntp: rpm -U ntp-4.2.4p0-2.fc7.i386.rpm (or just yum update)
[root@primary ~]# rpm --oldpackage ntp-4.2.4p0-1.fc6.i386.rpm rpm: only installation, upgrading, rmsource and rmspec may be forced [root@primary ~]#
Sorry typo, I forgot the -U I just did it awaiting ntpd to sync up. Nope its still not locking on the 1PPS :( [root@primary ~]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *SHM(0) .GPS. 0 l 18 16 17 0.000 9.149 1.294 SHM(1) .GPS1. 0 l - 16 0 0.000 0.000 0.001 x1.tonyurban.co 134.84.84.84 3 u 63 64 1 233.992 -163.63 0.001 dake.desynched. 129.6.15.28 2 u 62 64 1 226.602 -153.59 0.001 silk.lonewander 64.34.87.66 3 u 61 64 1 175.674 -275.82 0.001 192.168.0.255 .BCST. 16 u - 64 0 0.000 0.000 0.001 10.255.255.255 .BCST. 16 u - 64 0 0.000 0.000 0.001 NTP.MCAST.NET .MCST. 16 u - 64 0 0.000 0.000 0.001 LOCAL(0) .LOCL. 10 l 57 64 1 0.000 0.000 0.001 [root@primary ~]#
I also checked, the gpsd package is for fc7 Installed Packages gpsd.i386 2.34-3.fc7 installed Back now to the f7 ntp version, its just the same as the above fc6 ntp. [root@primary etc]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *SHM(0) .GPS. 0 l 9 16 377 0.000 0.147 1.788 SHM(1) .GPS1. 0 l - 16 0 0.000 0.000 0.001 +x1.tonyurban.co 134.84.84.84 3 u 4 64 37 234.519 -168.48 1.155 +ns37256.ovh.net 130.159.196.118 3 u 4 64 37 319.186 -170.57 0.538 silk.lonewander 64.34.87.66 3 u - 64 27 175.565 -336.31 15.469 192.168.0.255 .BCST. 16 u - 64 0 0.000 0.000 0.001 10.255.255.255 .BCST. 16 u - 64 0 0.000 0.000 0.001 NTP.MCAST.NET .MCST. 16 u - 64 0 0.000 0.000 0.001 LOCAL(0) .LOCL. 10 l 60 64 17 0.000 0.000 0.001 Can you read my bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242211 I say it has to be the kernel as someone said there are timekeeping changes in it. Can we get that bug reopened? There is something broken in F7 as it used to work and how it does not. Let me know any files you need. Here is the extract from my ntp.conf, but this iks timestamped from fc6 and I know its untouched and worked... # Use GPSD server 127.127.28.0 minpoll 4 maxpoll 4 fudge 127.127.28.0 time1 0.000 refid GPS server 127.127.28.1 minpoll 4 maxpoll 4 prefer fudge 127.127.28.1 refid GPS1 We know GPSD works, I get broadcasts and ntp is happy enough to use it, just the 1PPS is not working.
Then it doesn't look like a bug in ntpd. If I understand how gpsd works correctly, it doesn't use PPS API of kernel but interprets pulses emitted on port itself. Maybe running gpsd -D 5 would show if PPS is detected?
Yes that is correct how the 1PPS is detected. I better file a bug against gpsd, as you said its not looking like ntpd.
I filled bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243026 for gpsd. Do you think a serial port bug, where the pulsing DCD line is not getting detected?
Do you see any pps messages when the following command is started? /usr/sbin/gpsd -n -N -D 5 /dev/ttyS0 2>&1 | grep -i pps Also you could try statserial /dev/ttyS0, if you can see changing status on DCD.
Created attachment 156453 [details] gpsd full diag log You can see the PPS messages but while its still trying to sync. Once it has synced its stopped. So a bug in gpsd!
(In reply to comment #13) > Created an attachment (id=156453) [edit] > gpsd full diag log > > You can see the PPS messages but while its still trying to sync. Once it has > synced its stopped. > > So a bug in gpsd! Which is very strange, as gpsd has not changed at all (other than a recompile) for F7. I'm at a loss on how to fix gpsd given there was no change.
There is obviously some change in F7 that gpsd needs to take into account so it works properly :( I opened a bug for gpsd as it has a bug in F7. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243026 As you can see in the gpsd diag, its detecting the DCD 1PPS early on as its syncing up, then gives up and does not try again by the time its running 4800 nmea mode.
Thanks to some amazing help from Mick we proved it was gpsd at fault and compiled a working gpsd with PPS support for F7
This was originally the ntp bug for this issue; but there is already a gpsd bug for this issue, so marking it as a dupe (so there's only one open report). *** This bug has been marked as a duplicate of 243026 ***