Date:	Mon, 23 Feb 2009 07:58:01 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Rodolfo Giometti <giometti@...ux.it>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Dave Jones <davej@...hat.com>, Sam Ravnborg <sam@...nborg.org>,
	Greg KH <greg@...ah.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Kay Sievers <kay.sievers@...y.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	John Stultz <johnstul@...ibm.com>
Subject: Re: [PATCH 1/1] LinuxPPS core support.


* H. Peter Anvin <hpa@...or.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists