Red Hat Bugzilla – Bug 242211
Kernel is not compiled with 1PPS for GPS use
Last modified: 2007-11-30 17:12:05 EST
Description of problem:
Kernel is not compiled with the 1PPS for GPS use by PPS from the GPS pulses the
DCD line on the serial port.
Meaning for time sync use your going to have a very innaccurate time source.
Version-Release number of selected component (if applicable):
Completely the kernel does not support the 1PPS
Steps to Reproduce:
PPS support is not in the Linux kernel, it has only recently been proposed.
FC6 standard kernel (not xen) was compiled with 1PPS, as ntpq -p showed it was
locked to GPS1 as primary, which is the 1PPS.
I have been with FC6 almost from the start and never had to compile a kernel for
Can you check on this, as if the FC6 kernel is not compiled with 1PPS then
something is broken in F7 as it refuses to work 1PPS
[root@primary ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
*SHM(0) .GPS. 0 l 7 16 377 0.000 7.924 2.087
SHM(1) .GPS1. 0 l - 16 0 0.000 0.000 0.001
+securemail.nets 126.96.36.199 2 u 26 64 377 236.466 -163.06 0.677
-dedibox.bitschi 188.8.131.52 2 u 40 64 337 310.908 -166.76 0.676
+cronos01.nighto 184.108.40.206 2 u 39 64 377 224.506 -155.94 0.373
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 40 64 377 0.000 0.000 0.001
I now don't have a FC6 machine to show you, but with the stock FC6 kernel it showed:
So it was using 1PPS
The reply above this one is from the same server now running F7
There is no PPS support in the kernel itself, but the entire timekeeping
system was updated for kernel 2.6.21. Possibly the kernel option
"nohz=off" would help.
Thanks for this, I will reboot the server using the option and report back.
No did not fix the issue :(
Can we reopen and modify this bug please. The server I am using needs to
generate accurate time source and a non 1PPS output just does not cut it. It
was perfectly stable on FC6 and this is the only drama I am facing with F7.
I don't think I can take this. My GPS delivers the data through
the 1s NMEA tick on the data lines, I just eat the resulting jitter.
Without the hardware I can't tell what went wrong.
I don't think kernel ever had the support for 1PPS on DCD specifically.
There may be support for special 1PPS interfaces, but that's different.
NTP just sits in an ioctl getting the status or tries to open ttyS0.
A good way to triage this would be to take an FC-6 root and graft
the FC-7 kernel on top with rpm -i. They are compatible enough to
run tests. If ntpd fails, it's kernel's fault. Otherwise, it's ntpd.
Can we find out if the FC6 kernel ever had 1PPS capability? I am reluctant to
play too much and break the server.
If you can find out then we know if its kernel or ntpd.
But can we then after finding this out open a new bug if this one must remain
It is certainly a bug in the kernel or ntpd as it used to work and no longer
does. The gitter is unacceptable for precise timing applications, that is why
you pay a lot more for a 1PPS GPS and use it as a time source.
I am happy to test a 1PPS compiled kernel or a modified fc7 ntpd.
There are only 3 things involoved, kernel, ntpd and gpsd. Since gpsd is the
same version and supports 1PPS its obviously one of the other two.
Even if its a low priority bug as long as it gets resolved and not left broken
and closed :( .