Bug 242211 - Kernel is not compiled with 1PPS for GPS use
Kernel is not compiled with 1PPS for GPS use
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2007-06-02 04:10 EDT by David
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-04 12:33:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David 2007-06-02 04:10:11 EDT
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):

How reproducible:
Completely the kernel does not support the 1PPS

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Chuck Ebbert 2007-06-04 12:33:17 EDT
PPS support is not in the Linux kernel, it has only recently been proposed.
Comment 2 David 2007-06-04 18:20:44 EDT
Hi Chuck,
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     2 u   26   64  377  236.466  -163.06   0.677
-dedibox.bitschi   2 u   40   64  337  310.908  -166.76   0.676
+cronos01.nighto      2 u   39   64  377  224.506  -155.94   0.373   .BCST.          16 u    -   64    0    0.000    0.000   0.001  .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
[root@primary ~]#
Comment 3 David 2007-06-04 18:26:31 EDT
I now don't have a FC6 machine to show you, but with the stock FC6 kernel it showed:

#SHM(0) .GPS
*SHM(1) .GPS1

So it was using 1PPS

The reply above this one is from the same server now running F7
Comment 4 Chuck Ebbert 2007-06-04 18:53:41 EDT
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.
Comment 5 David 2007-06-04 18:57:54 EDT
Hi Chuck,

Thanks for this, I will reboot the server using the option and report back.
Comment 6 David 2007-06-04 19:04:50 EDT
Hi Chuck,

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.


Comment 7 Pete Zaitcev 2007-06-04 20:10:01 EDT
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.
Comment 8 David 2007-06-05 05:52:03 EDT
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 :( .


Note You need to log in before you can comment on or make changes to this bug.