[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] gpsd processor load

From: Andy Walls
Subject: Re: [gpsd-dev] gpsd processor load
Date: Thu, 31 Oct 2013 10:11:31 -0400

On Thu, 2013-10-31 at 09:27 -0400, Greg Troxel wrote:
> It would be good to actually understand the details of how PPS works on
> various systems before changing things.  esr asked about making the time
> service howto less Linux-centric (which I interpret as making the Linux
> content clearly identified as Linux-specific, with a structure to add
> peer subsections for other systems), and it seems we're doing the same
> thing about the PPS code.
> Details of PPS interfaces don't belong in a user-facing howto (just how
> to use them), but I'm curious about what's standard vs OS-local.  My
> impression is that the main standard is RFC2783, and this is implemented
> in some form on at least Linux, FreeBSD, and NetBSD, and perhaps some
> Solaris flavors (although the Solaris variant world has gotten pretty
> complicated in the last few years).

RFC1589 also is relevant, as ntp_adjtime() is used by ntpd to control if
the kernel clock discipline uses PPS.

The Linux kernel includes RFC1589 and RFC2783 functionality.

The Linux pps-tools package provides the needed timepps.h header for
RFC2783, the Linux kernel does not.

For the Linux kernel implementation of RFC1589 and RFC2783 to be fully
functional, one needs to ensure the following kernel configuration
options are included during the kernel build:


and that

        CONFIG_NO_HZ is not set - it disables CONFIG_NTP_PPS

FWIW, optional Linux kernel components (OS local?) for PPS can be built

        CONFIG_PPS_CLIENT_GPIO   (/dev/pps? from a gpio)
        CONFIG_PPS_CLIENT_LDISC  (/dev/pps? from a tty line discipline that 
snoops DCD)
        CONFIG_PPS_CLIENT_KTIMER (/dev/pps? from a fake pps source using kernel 
        CONFIG_PPS_CLIENT_PARPORT (/dev/pps? from a parallel port interrupt 

> My (vague so far) understanding is that pps support in ntpd relies
> solely on RFC2783. 

Certain controls on the kernel clock discipline also rely on RFC1589.

I.e. RFC1589's ntp_adjtime() is needed to set the STA_PPSTIME and
STA_PPSFREQ flags, so that the binding done with RFC2783's
time_pps_kcbind() actually has an effect.

On Linux, adjtimex() is also available to set those flags, but
adjtimex() is non-standard AFAICT.


>  If gpsd can do similarly without any deficits, that
> sounds like a good plan.
> Then, there is TIOMCIWAIT, which exists in Linux, and so far I'm not
> aware of it existing anywhere else.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]