[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
signature.asc
Description: PGP signature
- Re: [gpsd-dev] Direct GPS support in ntpd makes me nervous, (continued)
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Eric S. Raymond, 2013/10/22
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Gary E. Miller, 2013/10/21
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Hal Murray, 2013/10/22
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Eric S. Raymond, 2013/10/23
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Gary E. Miller, 2013/10/23
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Dave Platt, 2013/10/23
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO,
Gary E. Miller <=
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Eric S. Raymond, 2013/10/24
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Hal Murray, 2013/10/23
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Eric S. Raymond, 2013/10/23
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Gary E. Miller, 2013/10/23
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Beat Bolli, 2013/10/23
Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Miroslav Lichvar, 2013/10/23