gpsd-dev
[Top][All Lists]
Advanced

[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 11:59:18 -0700

Yo Dave!

On Wed, 23 Oct 2013 11:00:57 -0700
Dave Platt <address@hidden> wrote:

> 
> > 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.
> 
> Most distro Linux kernels do support the Linux "real-time" scheduling
> priorities, I believe.

Uh, no.  A common misconception. the realtime patches do not even apply
to a recent kernel!

> If gpsd/ntpd/whatever were to "bump" its
> PPS thread up to this priority before dropping root privileges, then
> the thread would be able to preempt compute-bound user processes
> immediately (before the end of the normal time-slice quantum).

gpsd already does this.

> Until a few years ago, preemption could have been blocked for a while
> if the lower-priority thread was in the middle of a syscall... but
> I believe that most distributions now ship with kernels that support
> preemption, so even this latency is no longer all that much of an
> issue.

On multicore x86 suure.  Not so on embedded ARM, etc.
>
> You do need to make sure that your real-time thread isn't going to
> get stuck in a loop somehow, as it *will* block all non-real-time
> processes from running on a mono-core system until it voluntarily
> relinquishes the CPU somehow.

We do.

RGDS
GARY
---------------------------------------------------------------------------
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]