[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] SHM refclock improvements
From: |
Gary E. Miller |
Subject: |
Re: [gpsd-dev] SHM refclock improvements |
Date: |
Tue, 28 Aug 2012 15:51:58 -0700 |
Yo Hal!
On Tue, 28 Aug 2012 15:01:51 -0700
Hal Murray <address@hidden> wrote:
> > How will we be able to know if an ntpd is capable of the new SHM
> > mode??
>
> Plan one is to release a new ntpd that handles the new mode, wait for
> it to get widely distributed, then release a new gpsd that takes
> advantage of it. That's likely to take a long time.
gpsd is still fighting with major distros not updated to gpsd 3.x yet.
Should be simple to come up with a simple way to determine protocol
version.
> We could use 2 chunks of shared memory. gpsd writes to both, ntpd
> uses a mode bit or tries both.
That could work. Or what about the pipe protocol that gpsd uses with
chronyd?
> Back to the original problem:
>
> address@hidden said:
> > We're looking to improve NTP's SHM refclock interface.
>
> I looked carefully at this stuff several years ago and I couldn't
> convince myself that it would actually work correctly. I forget the
> details. I may be able to reconstruct something. This stuff is
> tricky. The details probably depend upon the machine architecture.
Yes, and trying to get gcc to not optimize out, and properly fence, the
SHM access is a bitch.
> A year or 2 ago, there was a proposal to do-it-clean and use pthreads
> locking. I think the discussion was on usenet. That's a nice idea,
> but I don't know how to write the code for this case. Does pthreads
> support locking when memory is shared between jobs rather than
> different threads or forks in the same job? The problem is who does
> the initialization? We don't know which side gets started first.
> What happens if one side crashes and restarts? There should be a FAQ
> that covers this, if only to say "don't do it".
Threads are so controversial and non-portable I would prefer not to
touch that idea.
> I used to work with people who were wizards at this stuff. I asked
> one of them how to do it. His suggestion is roughly:
[...]
> X and Y need to be sized so they are atomically updatable. The code
> also needs cache flushes in the right places. I think a cache flush
> is a no-op on x86. I think it needs real code on ARM and others.
> There should be a FAQ on this, but I didn't find it with a quick
> search.
Yup. Every CPU is different. Even CPUs in the same family vary in
how to get atomics right. C compilers, if they give any support at all,
use hackish ways to get it right.
So, any reason NOT to go to named pipes like chronyd?
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
- [gpsd-dev] SHM refclock improvements, Harlan Stenn, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Gary E. Miller, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Harlan Stenn, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Hal Murray, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements,
Gary E. Miller <=
- Re: [gpsd-dev] SHM refclock improvements, Harlan Stenn, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Gary E. Miller, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Dave Platt, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Harlan Stenn, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Eric S. Raymond, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Hal Murray, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Eric S. Raymond, 2012/08/28
Re: [gpsd-dev] SHM refclock improvements, Miroslav Lichvar, 2012/08/29