lkml.org 
[lkml]   [2009]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] LinuxPPS core support.

* H. Peter Anvin <hpa@zytor.com> 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.

Ingo


\
 
 \ /
  Last update: 2009-02-23 08:01    [W:0.161 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site