[Top][All Lists]

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

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

From: Gary E. Miller
Subject: Re: [gpsd-dev] Clarifications needed for the time-service HOWTO
Date: Wed, 23 Oct 2013 10:54:57 -0700

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.


> > >     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

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

Attachment: signature.asc
Description: PGP signature

reply via email to

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