[ntp:hackers] [Gpsd-dev] Single-writer/many-reader consistency
terje at tmsw.no
Sat Mar 26 22:16:00 UTC 2011
Dave Hart wrote:
> [dropping gpsd-dev@ from this ntpd-specific comment]
> On Sat, Mar 26, 2011 at 21:26 UTC, Terje Mathisen<terje at tmsw.no> wrote:
>> 3) It overlays the current mode value, and none of the 8 bytes contain
>> either 1 or 0 which are the only legal values for the current interface,
>> i.e. a current-generation ntpd shm driver will never pick up any bogus
>> timestamps from a new-model gpsd.
> Assuming we're switching from SysV to POSIX named shared memory, and
> we change the Windows refclock_shm shared memory naming convention, we
> need not concern ourselves with interaction with the previous
> refclock_shm shared memory layout, right?
Yes and no:
Dave Mills will never allow us to make a brand new ntpd reflock driver,
we can only update those that are already there: We'll have to work with
the existing SysV code as the starting point, then use a 'mode 2' or
similar fudge flag on the driver configuration line in ntp.conf to
select the new interface.
> I wonder if anyone is using refclock_shm on Windows. The bk history
> isn't any help, rev 1.1 of refclock_shm.c (dating to 1999 and the
> introduction of RCS for NTP) contains the Windows stuff. I didn't
> glean anything useful from CommitLog-4.1.0 either. Google Code Search
> might turn something up, but a few quick tries suggest won't be easy
> to sift out the bazillion copies of the NTP distribution posted around
> the web.
I can try to do so, I have all the required hw in the form of a SURE
Electronics GPS evaluation kit ($32 with antenna! <bg>), and a docking
station for my W7-64 laptop which has a real RS232 port.
I have tested gpsd+ntpd on Ubuntu, but that laptop didn't have a proper
serial port, only a USB-RS232 converter which results in ~1ms of jitter. :-(
I do have a couple of old laptops with serial ports, they run FreeBSD.
> The search did point out we're carrying around a util/sht.c test
> program associated with refclock_shm which hasn't been updated in
> Terje, I've been debating whether I have the focus and energy to dive
> into a test program to try out your idea at an accelerated rate
> (specified on the command line) with a producer and a couple of
> consumers forked or threaded off pounding away attempting to detect
> corruption. Are you interested in trying something like that?
For a test I'd let the writer update _much_ more often (once per us or
so?) and write special timestamps with internal consistency checks, then
have 3 more threads/processes all reading and looking for inconsistent
I am thinking that the timestamps fields can contain a simple checksum
in the least significant bits, plus a sequence number in N bits above
that so that each reader can detect both inconsistent and missed reads.
I'm going to bed now (late night here in Oslo, Norway), but I'll write
that test code tomorrow and report back!
- <Terje at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
More information about the hackers