Troubleshooting NTP with NI Hardware

Troubleshooting NTP with NI Hardware

In order to synchronize DAQ timestamps or time-sensitive processes across devices, you need to establish a common time source to which all devices on a network can synchronize. 

Network Time Protocol (NTP) services provide this functionality, through which multiple networked machines may reference a common time source. However, issues can arise when a project requires National Instrument's LabVIEW with NTP. There is not much online in terms of bridging the gap between the engineers who need NTP functionality and the networking specialists who know how to set up this service.

If you end up spinning your wheels, this blog details a solution and tips to deal with to those issues.

Why Is NTP With LabVIEW An Issue? 

The important nuance here is that NI hardware does not support NTP 3.0 standards and requires an NTP service built upon NTP 4.0. The pre-installed NTP service on a Windows PC is win32time (which is NTP 3.0) and can cause some headaches when setting up your system time sync.

Therefore, first thing's first. Download Meinberg's NTP (make sure it's version 4.0 or later) on every PC you are going to synchronize. At the end of the installation, check the box that allows you to view and edit the configuration file before starting the service.

Defining NTP Terms

As we move further into the technical aspects of this solution, let's define a few terms:

  1. Stratum - The number that sets the hierarchy of your time sources. A stratum 0 IP is the IP of your end-all-be-all 'perfect' time source. This is ideally something that you would point all of your devices to as their 'ideal' state. A higher stratum number denotes a less accurate or ideal time source.

  2. Restrictions - The set of parameters which set the restrictions of a specific IP (or a set of IPs) on what information it may obtain or send through this NTP service. Any non-specified IP addresses will follow the restrictions imposed on 'default' IP addresses. These restrictions should be as specific as possible to avoid potential network security risks.

  3. Server - A time source specified by the device's IP address. This can be a PC's internal system clock (, another device, or the widely-referenced NTP Pool server set.

  4. Client - Any device that calls upon a server as its reference is a 'client' of the server.

  5. Peer - A device on a common stratum level which should share timing with other peers. Two devices who name each other 'peer' will strive to meet their server time(s) as a unit. Ideally, any number of equal peers should share the same servers.

  6. Peer-to-Peer - The relationship formed between two devices (usually on the same stratum) who name each other 'peer' in their configurations.

  7. Server-Client - The relationship formed when a device of a higher stratum is configured to converge to the time of a lower-stratum server time source.

Three Tips Before Getting Started

TIP 1: There is nothing that says that you cannot have a low-stratum ("more accurate") client using a high-stratum ("less accurate") server in their NTP service except that it will not "prefer" the server over its own internal clock or another specified time source. Use the "prefer" keyword in your configuration statement to override the automated selection of a preferred time source.

TIP 2: Peers can be defined with different stratum levels, but this will likely revert to server-client relationship behavior even if it is not what you intended.

TIP 3: Allow inbound and outbound access to ntpd.exe and ntpq.exe in your firewall settings for NTP communications to be established.

Setting Restrictions, Servers, Peers, and Architecture

The configuration file for your machine and the place where you will define your service is ntp.conf.

This is the file which you will be looking at if you had the box checked to edit the configuration before starting the Meinberg NTP service. Otherwise, open ntp.conf as Administrator from Program Files (x86)\NTP\etc\ntp.conf.

Once opened, you will need to set your restrictions, servers, peers, and architecture for the NTP service.

Below are examples of what sections you may need to ensure are included in the configuration file (ntp.conf) for certain scenarios.

% allow localhost (the computer's loopback interface for adjusting internal timing) status queries (don't include if this is your 'master' time source)
listen on

% listen to local system clock as a server, but make it high stratum so that it will prefer other sources
fudge stratum 12 % set stratum 0 if the local system clock is to be the 'master' time source

% listen to local system clock as a server, and make it low stratum so that all clients of this device will prefer this source
fudge stratum 0

% set an IP as a server you wish to use as a time source and make it the preferred source regardless of stratum definitions
server <IP address> prefer

% peer with another device (usually of the same stratum)
peer <IP address>

% allow client devices to listen to the device as a server
Listen on <client IP>

% Use drift file for calculating clock adjustments (everything that is adjustable should have one)
driftfile "C:\Program Files (x86)\NTP\etc\ntp.drift"

Additional Considerations For NTP 

There are many options that can be set in this configuration file. You will need to be sure that every device has the NTP software installed and that the configuration files agree to give you your desired result. NI hardware can be configured through MAX to point to a specific IP address (like our NTP server or a connected PC). Search NI help pages for instructions on how to configure your specific device's NTP service. 

One important thing to note about the configuration file is that while it does rigidly define permissions and what devices are connected, it does not rigidly define the structure of your NTP service. However, this is one of the great benefits of NTP. Should you lose connection with your common stratum 0 time source, for example, the system can adapt to find the next-best time source based on defined stratum as well as connection and timing reliability.

Be sure to restart the service after editing your configuration files. To do so, run restartntp.bat. Then, give this service some time to come to a steady state. There is a closed control loop behind the scenes which will work to bring your NTP service to steady state as defined in the configuration file.

To check on your current NTP service state for a given device, enter "ntpq -p" in command prompt to see some useful information regarding your current connections and clock offsets.



  2. Meinberg NTP Configuration commands cheat sheet

  3. NI support page with installation instructions


There are currently no comments, be the first to post one.

Post a comment

Name (required)

Email (required)

Enter the code shown above:

Related Blog Posts