Bug 242211

PPS support is not in the Linux kernel, it has only recently been proposed.

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
1PPS.

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 128.59.39.48     2 u   26   64  377  236.466  -163.06   0.677
-dedibox.bitschi 195.220.94.163   2 u   40   64  337  310.908  -166.76   0.676
+cronos01.nighto 192.5.41.40      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
[root@primary ~]#

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

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.

Hi Chuck,

Thanks for this, I will reboot the server using the option and report back.

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.

Cheers,

David

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
closed?

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 :( .

Thanks!