Re: [gpsd-dev] Clarifications needed for the time-service HOWTO

[Gary E. Miller]

Yo Eric!

On Wed, 23 Oct 2013 13:33:19 -0400
"Eric S. Raymond" <address@hidden> wrote:

> Gary E. Miller <address@hidden>:
> > > What sorts of jitter are produced by different parts of the
> > > delivery chain?  What do typical magnitudes look like?
> > 
> > The jitter from NMEA on a local GPS can be a few hundred mSec.  Run
> > a traceroute to a server and you see how bad you network can be.
> > Cable modems could be up to 500 mSec (and they are wildly
> > asymetric).  The jitter from a local GPS s defined by the USB
> > transfer, around 1 mSec for USB 1.1 The jitter from interrupt
> > processing can be 100uSec and sometimes much worse on a loaded
> > system.
> 
> I'm not sure how to use those figure for the HOWTO.  Can you
> recommend a specific way to merge them?

Maybe we just need a table of typical error sources and magnitudes?  No
need to get into the specifics.

> > >     Thus, KPPS can only be used with devices passed that way, not
> > > with GPSes that are later presented to gpsd by the hotplug
> > > system.  Those hotplug devices will, however, may be able to use
> > > plain, non-kernel PPS. gpsd tries to automatically fall back to
> > > this when absence of root permissions makes KPPS unavailable.
> > 
> > Before saying this I would like to see it tested.
> 
> Has been.  I've seen PPS from a GR601-W using gpsd started as
> non-root.
> 

Cool.

> > >     1. Devices passed on the command line will be unable to use
> > > KPPS and will fall back to the same plain PPS that all hotplug
> > > devices must use, increasing the associated error from ~1 uSec to
> > > about ~5 uSec.
> > 
> > Or ptotentially MUCH worse on a single core CPU.
> 
> Why is single-core vs. multicore relevant here?  And can you give an
> estimate of "much worse"?

Linux is not a 'real-time' system.  Linux schedules a task and that task
runs until it performs a system call, or hits a timeout.  The timeout
may be many mSec on a slow CPU.

If there is one core, and you are doing a compute intensive operation,
then the PPS interrupt may be delayed a long time.  Once the PPS thread
is woken up a time stamp is taken.  That adsd some amount of latency
and jitter.

If you have a multicore system, the OS tends to put the long jobs on one core,
and itnerrupts on another.  That way the big compute job gets to run a
long (and efficient) time and another core is ready to handle the
PPS interrupt.  This yields less latency and jitter of the plain PPS
handling.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

signature.asc
Description: PGP signature