2013/8/23, Martin Burnicki <[email protected]>: > David Taylor wrote: >> On 20/08/2013 13:25, Martin Burnicki wrote: >> [] >>> There were 2 fields in the SHM segment which were previously unused and >>> are now used to take the nanoseconds from the refclock and from the >>> system time. >>> >>> Thus programs like gpsd can now write the nanoseconds in addition to the >>> microseconds. If there's an old version of ntpd running then it just >>> evaluates the microseconds, but new versions (ntp-dev for now) check if >>> the nanoseconds fields are filled up and use them if this is the case. >>> >>> Thus an old ntpd works with a new gpsd, and a new ntpd works with an old >>> gpsd. See: >>> >>> Bug 1232 - nanosecond support in SHM driver >>> https://bugs.ntp.org/show_bug.cgi?id=1232 >>> >>> Martin >> >> Is SHM supported on Windows? I know that it /could/ be as the >> mechanisms exist within the OS, but /is/ it? > > I'm afraid it is not. > > A quick look into the config file for Windows for the current ntp-dev > version shows that support for the SHM driver is commented out. > > I have also worked with shared memory under Windwos for the driver > software for our PCI cards, Windows uses completely other API calls for > the shared memory support, and thus "someone" needed to port the SHM > driver in ntpd to Windows first.
Yes, SHM driver is commented out but look at refclock_shm.c. The shm refclock supports Windows and it's added over 15 year ago (according to the BitKeeper). ps. I don't know if it works? _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
