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

Terje Mathisen terje at tmsw.no
Wed Mar 30 17:29:20 UTC 2011


todd glassey wrote:
> On 3/28/2011 11:23 PM, Terje Mathisen wrote:
>> todd glassey wrote:
>>> On 3/27/2011 1:17 PM, Terje Mathisen wrote:
>>>> As I promised I've written a test program, with one writer and 3
>>>> readers (I have 4 cores so all run at all times, I force them to be on
>>>> separate cores).
>>> What happens with Hex or dual cpu machines? Does the performance scale
>>> as well or is it tied to a single-substrate?
>>
>> The maximum update rate will probably be _slightly_ lower on a
>> multi-chip system, but not by too much.
>>
>> Anyway, since it is currently running about 5 orders of magnitude
>> faster (13 MHz) than what's needed for a 100 Hz GPS, I really don't
>> worry about it.
>
> My concern is for a shared memory model across a cloud or new C4 type
> infrastructure (this is a new array type model with an incredibly fast
> bus). Also remember I use NTP as a source of evidence and so my overhead
> models are about 2000 times what normal NTP uses today use.

Running shm across a distributed shared memory cluster is really 
inefficient!

Plain NTPD, either in client server or multicast/broadcast 
configurations would be much, _much_ less overhead.

Besides, the gpsd-ntpd shm interface can only work if all the cpus 
involved share a common system clock (since the timestamps are all 
relative to the system time on the gpsd host), and if they do have a 
common clock, like the classic IBM mainframe SysPlex setup, then they 
have no need for shm to synchronize the various cpus: They are already 
identical!

I.e. this particular issue simply cannot occur.

On an SMP machine we _could_ solve all the sync problems by simply 
forcing gpsd and ntpd to run on the same core at all times, i.e. 
effectively turning the multicore setup into a single-cpu machine with 
regard to timestamps.

Since shm-test have shown that we can use shm to communicate timestamps 
between physical cores with sub-us overhead, we don't need to do this!

Terje

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


More information about the hackers mailing list