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

[Dave Platt]

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

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.