Re: [Hampshire] Kernel compilation

2009/9/17 Graeme Hilton <graeme.hilton@???>:
> Hi,
>
> This is one for the kernel hackers amongst you.
>
> I've got a system [1] on which I have installed CentOS 5.2.
> Everything I need to use works out of the box with kernel 2.6.18-92.
>
> However, I've recently been asked to add the ability to synchronise
> the internal clock with a GPS time source and have it keep very
> accurate and precise time.  So I bought a PXI GPS card [2].  This
> presents itself as a serial port to Linux and provides data to
> programs such as gpsd.  This sounds good until you realise that the
> timestamps provided are only accurate to about 0.5s - not good enough!
>
> The GPS also provides an output called PPS - pulse per second which is
> accurate and precise to within 1us.  This is connected to the DCD pin
> on the serial port.
>
> The latest kernel 2.6.31 has just included some code to utilise this PPS signal.
>
> So, I need to get this kernel compiled to work on my system.  This
> isn't proving to be easy!  As I said earlier the 2.6.18 kernel from
> CentOS works fine so I took this as the starting point and set about
> compiling subsequent versions.  Everything up to 2.6.27 works fine
> using the default options.  On 2.6.27 the kernel can't find the root
> filesystem and so cannot complete booting.  I think this is either due
> to a missing SATA driver (although there's only one disk and grub
> manages to get started from it) or a missing filesystem (I use only
> ext3, which is compiled in).
>
> Attached is the boot sequence captured on the serial port from kernel
> 2.6.27.  It doesn't include the text that only appears on the screen
> that refers to the kernel being unable to find a root filesystem.
>
> Any hints on how to get more information out of the kernel or on what
> I should be looking for are more than welcome.
>

With regards to the timing, I am involved in the Galileo project, that
is a European Global Positioning system like the USA's GPS.
You have to maybe relax your accuracy expectations. Linking a PPS
serial input to a non-real time Linux system is not going to give you
an excellent result. What you are dealing with is in some ways similar
to an IRIG-B signal.
In order to get accurate time, one has to have three things
1) A precise free running clock.
2) The PPS signal to calibrate the clock.
3) A timestamp attached to the PPS signal (tells one which second the
pulse is for)
One uses the PPS signal to take a sample timestamp from the precise
free running clock.
This timestamp will not be too accurate on a Linux box because one has
interrupt latency affecting when the PPS signal triggers a timestamp
sample. This can be improved on embedded platforms, because one can
remove hardware that might contribute to interrupt latency. (HDs and
graphics cards, DMA transfers)
So, over time, one has a number of timestamps taken at 1 second intervals.
One then uses various filtering algorithms to arrive at correction
values to apply to the free running clock.
Then one uses free-running-clock, corrected with correction values =
accurate time.

Where is your "precise free running clock" ?
Your final accurate time will only be as phase accurate as the free
running clock.
If your free-running-clock is not too accurate, all that the PPS
signal will give you is accurate to +-1 second over the entire year.
I.e. The accuracy will not drift over the year.
free-running-clocks drift over time, which is why one's digital watch
is only accurate to about +-10seconds per month.

I just wanted to make sure that you understood what the PPS signal
would give you.
It does not make the time more instantaneously accurate, it reduces "drift".
You need a better free-running-clock to make it more accurate
instantaneously, which is why atomic clocks are used when one needs
more accurate instantaneous time value.

I would have opted instead for a stand alone GPS to NTP box, and
simply used NTP on your Linux box. The end result is likely to be very
similar.

Kind Regards

James