Platform support policy

We expect the NTPsec code to run with at most minor port changes on Unix-like operating systems conforming to POSIX.1-2001 and ISO/IEC 9899:1999 (aka C99) and supporting both ntp_gettime(2)/ntp_adjtime(2) and the POSIX-1.2008 clock_gettime(2)/clock_settime(2) calls. Either Python2.x:x >=6 or Python 3.x:x >= 3 are also required. We will fully support these platforms.

(Note: in the future it is possible we may drop support for Python 2.6, moving to a baseline of Python 2.7.2.)

Hardware with 32 or 64 bits and any endianness is supported. However, we’re optimizing for performance on modern 64-bit hardware and will sacrifice performance on older systems to tune for newer ones.

NTP Classic kept legacy support for a lot of very ancient Unix big iron, and for other systems, such as VMS. But increasing security requires reducing complexity and attack surface. We have almost completely removed legacy Unix support, and our direction is towards dropping the remainder (along with unused or rarely-used features) in order to achieve secure simplicity.

The support for building under legacy Windows toolchains has been removed to reduce complexity. We may re-port to Windows using modern, more POSIX-conformant tools, but that is unlikely in early releases. Help with this would be welcome.

If you are a stranded legacy user with security and reliability requirements strong enough that only NTPsec will do, our team is open to working with active port maintainers who will take responsibility for specific target environments not fully conformant to the POSIX.1-2001/C99/Python-2.6 combination, or for exotic hardware.

Our primary development platforms are Linux and FreeBSD.

NTPsec builds cleanly on at least the following systems:

Some of these systems have minor build quirks; see the INSTALL file in the distribution root directory for details

Normal time sync in client mode works correctly on all the listed systems. Server mode has been well tested under Debian and Raspbian, less so on other variants and *BSD.

However, platform dependencies other than adjtime(2) and adjtimex(2) are minimal. Experience with the codebase suggests it will run correctly anywhere it builds correctly.

The following refclocks are known to work under Linux:

The best-tested refclock on non-Linux systems is SHM, especially in combination with GPSD.

We have an actively maintained port to macOS
[Pre-10.12 versions of Mac OS X have a defective or nonexistent clock API; we are no longer attempting to support these.]
. Basic testing has been performed and we are looking for people with macOS skill and interest to help support this platform and perform detailed testing.

We regularly test not just on x86 but on the ARM processors in the Raspberry Pi 2 and 3. This gives us both a test for hidden platform-centric assumptions and useful pressure to stay friendly to small systems.