Kernel - why the need to recompile to add PPS support?

On Fri, 20 Dec 2013 16:50:31 +0000, David Taylor wrote:


Are you sure you need PPS support?  
What type of device are you trying to link to ntpd?

The NTP server, ntpd, runs quite satisfactorily on the standard Raspbian  
kernel using the standard internet time services as its master time  
source. That was one of the first things I configured and had running on  
mine.

Have you considered using GPS receivers with NMEA output?

This one, for instance:
(Amazon.com product link shortened)
B008200LHW/ref=pd_cp_ce_1
Is powered through its USB connector and uses gpsd to interface it to  
ntpd. gpsd is a standard Debian package for connecting GPS receivers that  
use the NMEA protocol to ntpd.

Garmin also sell similar receivers but they generally need a 12v power  
supply and use serial connections, so you'd need a 12v PSU and a serial  
to USB adapter to connect them to an RPI. That said, suitable models are  
the Garmin GPS18 GPS19 (current models), GPS25 or GPS35 (look on eBay).  

More detail on using gpsd is here:
http://www.rjsystems.nl/en/2100-ntpd-garmin-gps-18-lvc-gpsd.php

If the above doesn't help, you may want to ask on comp.protocols.time.ntp,  
which is apparently a good place to ask NTP-related questions.

GPS with NMEA is worthless for accurate time sync.
A network time source will normally perform much better.
(unless your network is via WiFi or UMTS/GSM of course)

GPS can be used as a good timesource but you need the PPS signal.
It can be fed to the kernel without PPS support, e.g. with gpsd.

However those that want PPS support usually know what they are talking
about and want it for some reason.

I think the PPS support changes more than just the addition of
some functions, that is why it is not a module.  The reason I originally
added PPS support to gpsd (which works reasonably well on a lightly
loaded system) was that I did not like to recompile the kernel
either.  It takes a long time and makes tracking security updates
from the distributor a lot more difficult.

On 20/12/2013 20:18, Rob wrote:


Thanks for your comments, Rob.  I have tried a user-mode program on the  
RPi which injects PPS times (from a specified GPIO pin) into the shared  
memory segment provided by (I believe) gpsd.  With this program I can  
get down to around 5 microseconds averaged jitter on the RPi.

   http://vanheusden.com/time/rpi_gpio_ntp

Using kernel-mode PPS (and ensuring that the kernel is not compiled with  
"tickless" set) reduces the averaged jitter to 1-2 microseconds.

It is a pity that the default Raspberry Pi software is not supplied with  
PPS support from a programmable GPIO pin, and without "tickless".

Ok I'll admit that I forgot we are on a Raspberri Pi, not NTP, group.
What gpsd can do is to receive GPS data on a serial port, and at the
same time receive PPS pulses on a handshake line of that port, usually
DCD.

However, while the Raspberri Pi does have a serial port, it does not
come with a handshake line.   So this function of gpsd cannot be used.
Of course it is possible to have another program running that inputs
a generic input pin and does the same thing as gpsd does.

The shared memory segment is not used by gpsd, it is used by ntpd.
It is filled by gpsd or the special program you use.

On 21/12/2013 09:05, Rob wrote:
[]


.. and gpsd works very well indeed - thanks very much for that!  The  
great thing about the user-mode program is that the pin to use can be  
specified on its command-line, whereas the kernel patch is to a port  
defined at patch time.

Well, I wrote the initial code for timesync in gpsd, but after me a
lot of other people have further refined it.  The command-line spec
of the input pin is one of those changes made by others.  In fact, when
I wrote my code I was asked not to use any configuration options, in
those days gpsd was supposed to be completely auto-configuring.

(the code auto-detects the presence and polarity of the PPS pulse)

kernel features can be re-configured by the kernel command-line

On 21/12/2013 11:20, Jasen Betts wrote:


Thanks, Jasen!  Well, please tell me more!  This is what I currently  
need to configure:

- Make the system /not/ tickless
- Enable PPS support
- Enable Generic memory mapped GPIO support

==================================================
General setup --->
     Timers subsystem ---> [ ]
         Tickless System (Dynamic Ticks)
Next turn on PPS support
Device Drivers --->
     PPS support --->
         <M>  PPS support
         [ ] PPS debugging messages (NEW)
         <*> PPS kernel consumer support
             *** PPS clients support ***
         < > Kernel timer client (Testing client, use for debug)
         < > PPS line discipline
         <M> PPS client using GPIO
Device Drivers --->
     -*- GPIO Support --->
         --- GPIO Support
         [ ] Debug GPIO calls
         [*] /sys/class/gpio/... (sysfs interface)
         *** Memory mapped GPIO drivers: ***
         <*> Generic memory-mapped GPIO .. (MMIO platform)
==================================================

in addition to applying this patch:

  
https://raw.github.com/lampeh/rpi-misc/master/linux-pps/linux-rpi-pps-gpio-bcm2708.diff

I suspect the patch is the killer, even if the three items above can be  
done in a command line.

I only know it's possible.  

On PCs there's paramteres like VGA and 8250_NR_UARTS
which configure setting of built-in code




yeah, these would be features you want would need to be compiled they
could be be enables or fine-tuned at boot-time  

many thing can be built as modules and configured at load-time by
similar means.

On 20/12/2013 20:01, Martin Gregorie wrote:


Thanks for your reply, Martin.  Yes, PPS is essential for precise  
timekeeping.  I am linking devices which have a PPS output such as:

Adafruit GPS:
   http://www.adafruit.com/products/746

and U-blox 7Q:
  
http://ava.upuaut.net/store/index.php?route=product/product&path59%_60&product_id95%

NMEA alone is totally inadequate for precise time-keeping, as the serial  
output has a low prority within the GPS receiver and can, consequently,  
have a very large jitter.  It may actually be worse than a reasonable  
Internet connection.

I am moderately familiar with NTP.  Do you have an answer to my question?

I'm trying something similar, but NTP has a broken way of specifying source
s.  My GPS has a very jittery serial data, but precise PPS - but NTP refuse
s to accept PPS when it departs from the GPS time, but the GPS time will be
 constantly moving.

But for the kernel, I have a project on github, https://github.com/tz1/pike
rnomatic that builds kernels, and gpio_pps that allows a module to be loade
d to specify the GPIO pin (since I'm swapping hardware the available pins c
hange).

Is there anyway to just use /dev/pps0 and ppsctl that bypasses NTP complete
ly and have the kernel itself sync to PPS?  (Or I might write my own to use
 adjtime).  I already have a GPS NMEA decoder that sets the time (actually  
a bit before due to serial latency) - that is webgpsd on github.

On 27/03/2014 19:22, snipped-for-privacy@gmail.com wrote:


I must confess to not having seen this problem myself, but I always use  
other NTP servers to set the coarse time.  You can mark the GPS serial  
server as "noselect", and just monitor it, if you like.

Are you allowed to connect to other NTP servers in the system you are  
building?  That might solve the problem.

NTP will need to have a way of knowing the coarse seconds - it can't  
work from PPS alone.  I'm wondering whether you may be in the situation  
of the man with two clocks, not knowing which is right, but if the PPS  
is working properly I would have expected NTP to choose it over the GPSD  
every time.  There may be parameters you can twiddle, but perhaps the  
best approach is to ask the gurus over on:

   nntp://comp.protocols.time.ntp

I have a feeling there's something obvious which I'm missing!  <G>