[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: Dave Platt
Subject: Re: [gpsd-dev] Clarifications needed for the time-service HOWTO
Date: Wed, 23 Oct 2013 11:00:57 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

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

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

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.

reply via email to

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