[ntp:hackers] [Gpsd-dev] Single-writer/many-reader consistency

Terje Mathisen 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
> ages.
>
> 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?

Sure!

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

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
-- 
- <Terje at tmsw.no>
"almost all programming can be viewed as an exercise in caching"


More information about the hackers mailing list