Re: [PATCH 1/1] LinuxPPS core support.

[Rodolfo Giometti]

On Mon, Feb 23, 2009 at 07:58:01AM +0100, Ingo Molnar wrote:
> 
> * H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> 
> > Ingo Molnar wrote:
> > >>
> > >> Common use is the combination of the NTPD as userland program 
> > >> with a GPS receiver as PPS source to obtain a wallclock-time 
> > >> with sub-millisecond synchronisation to UTC.
> > > 
> > > Hm. I was looking at this stuff with the prospect of adding it 
> > > to the timer tree, but i'm really struggling with a few 
> > > fundamental questions.
> > > 
> > > The most basic one is: why do we need this?
> > > 
> > > The main purpose of your current patchset seems to be to deliver 
> > > interrupt timestamps to user-space, where it will in essence be 
> > > used to feed new adjtimex adjustments via ntpd.
> > > 
> > > I.e. the whole thing comes around in a circle in the end, but 
> > > via user-space, where jitter will only increase.
> > > 
> > > Why not cut out the jittery middle man and add some intelligent 
> > > API to register PPS interrupt sources straight with the NTP 
> > > code, and let those IRQ timestamps be fed _directly_ into our 
> > > time adjustment code?
> > > 
> > 
> > Well, let's be fair here... the kernel-user space time model 
> > involving ntpd has been very carefully developed over a period 
> > of over a decade. It's known to work.  The userspace 
> > involvement isn't just about feeding the data to the local 
> > clock, but also -- or perhaps primarily so -- to keep the 
> > timing inside ntpd calibrated, as that is the time that will 
> > be provided to the outside world.
> 
> Sure thing, the policy bits should still be done by user-space - 
> something does have to know that there's a PPS device on the 
> serial, parallel or any other port, and has to configure set up 
> the actual parameters as well, etc.
> 
> What i'm pointing out is that there's no technical benefit from 
> passing the _timestamps_ through user-space and from not 
> coupling the NTP code with the PPS edges.
> 
> Nor has it really been designed into NTP that way. We already 
> have all the traditional PPS parameters in the NTP syscall 
> interface:
> 
> include/linux/timex.h:
> 
> struct timex {
> [...]
>         long ppsfreq;           /* pps frequency (scaled ppm) (ro) */
>         long jitter;            /* pps jitter (us) (ro) */
>         int shift;              /* interval duration (s) (shift) (ro) */
>         long stabil;            /* pps stability (scaled ppm) (ro) */
>         long jitcnt;            /* jitter limit exceeded (ro) */
>         long calcnt;            /* calibration intervals (ro) */
>         long errcnt;            /* calibration errors (ro) */
>         long stbcnt;            /* stability limit exceeded (ro) */
> 
> (these are the bits to query the state of kernel-side PPS 
> support.)
> 
> and we have the bits to enable a PPS line disciple, etc., etc. 
> We might need some extensions, but since the PPS device will be 
> handled by the kernel anyway and the NTP adjustments are done in 
> the kernel too, there's no strong reason to route the actual 
> timestamps via user-space. In fact, doing so obviously increases 
> jitter and slows down NTP convergence.

Precise time settings can be done in both kernel and user
spaces. RFC2783 specifies an API that can be used to fetch PPS
timestamps from a PPS source, then these timestamps can be processed
by an userland consumer (NTPD in most cases) to set up system time.

Again the RFC2783 specifies a way to manage some kernel consumers
which can do the same jobs in kernel land, but all these stuff are
declared as "optional".

I agree with you that passing timestamps to userland may increase
jitter and slow down NTP convergence but LinuxPPS is a way to have at
least one "precise" time setting tool! :) However, as far as I know,
the NTPD algorith should take in account such jitters (I'm sorry but I
cannot be more precise since I'm not a NTPD guru), in fact if these
timestamps are taken "as soon as" possible inside the IRQ handling
chain the NTP convergence speed up several times.

In any case, if we wish adding a more performance tool in kernel space
we can just do it as RFC2783 says and (maybe) managing it with the
struct above.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail: giometti@xxxxxxxxxxxx
Linux Device Driver                          giometti@xxxxxxxx
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/