join
donate

SHM Refclock Driver, V2

Related Topics: bug_small.png Bug #1232

History

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];
};

Wish-List

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

Discussion

 


This topic: Dev > WebHome > DevelopmentIssues > RefclockShmV2
Topic revision: r4 - 2014-08-08 - 22:34:22 - JuergenPerlinger
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback