During this season of giving, you can show your support for the NTP Project by making a donation to Network Time Foundation.

SHM Refclock Driver, V2

Related Topics: NTP-BUG 1232


refclock_shm.c says, in part:
To add new modes: Extend or union the shmTime-struct. Do not extend/shrink size, because otherwise existing implementations will specify wrong size of shared memory-segment

PB 18.3.97

struct shmTime {
        int    mode; /* 0 - if valid set
                      *       use values,
                      *       clear valid
                      * 1 - if valid set
                      *       if count before and after read of values is equal,
                      *         use values
                      *       clear valid
        int    count;
        time_t clockTimeStampSec;
        int    clockTimeStampUSec;
        time_t receiveTimeStampSec;
        int    receiveTimeStampUSec;
        int    leap;
        int    precision;
        int    nsamples;
        int    valid;
        unsigned clockTimeStampNSec;
        unsigned receiveTimeStampNSec;
        int    dummy[8];


  • Add a version number to struct shmTime
  • [done: Support nanoseconds]
  • We have a precision field. Do we also need a way to specify the particular CTL_SST_TS* value?
  • Support a layout and access strategy that works reliably with multi-core machines and relaxed memory ordering.
    (The current driver does not consider the requirements of lock-free programming for shared memory on modern machines.)
  • Support POSIX shared memory in addition to SYSV shared memory.
  • Have a more flexible way to configure the access rights. (Currently units 0/1 are root-only, all others are accessible by world.)

Proposed Changes

With ntp4.2.7 we have 32 mode bits, and all are unused by the SHM driver. The mode could be used to define
  • The type of shared memory (posix/SYSV), which is ignored for the Win32 platform.
  • The access rights (root/owner vs. world), which has a direct counterpart in Win32.
  • The layout of the SHM segment for alternate access methods. This will most likely involve using a different naming scheme for the SYSV and WIn32 SHM segments; since there is no structure version tag in the current layout, a client has no way to detect that such a clock has a different data layout.

Since changing the naming scheme in conjunction with another operation mode isolates these changes from the current implementation (which would become the 'mode 0 driver') backward compatibility can be maintained.

An alternate memory layout should consider
  • 32/64bit issues. Using 'int', 'time_t' and 'long' in a data structure for data exchange is a no-go on platforms where multiple compilers can be used and where 32bit and 64bit apps can run at the same time.
  • Using proper format description in the SHM data, including the expected mapping size. This enables clients to detect the required mode of operation and to either act properly or refrain from using the clock if they cannot support the mode.
  • Using a fixed-point format for the fraction of seconds. This oblivates the usec vs. nsec coding the driver uses currently. (It's a bit harder on the clients. But it might keep the server more stable.)
  • Reducing the collision probability in the SHM segment and having a recover/retry strategy if a collision is detected.
  • Handling the SHM in a style that is more in line with the current hardware.


Topic revision: r4 - 08 Aug 2014, JuergenPerlinger
Copyright © by the contributing authors.Use of this website indicates your agreement with, and acceptance of, the PrivacyPolicy, the WikiDisclaimer, and the PrivateWebPolicy.