Building a GPS Referenced NTP Server Part 3

Selecting a GPS receiver for use as a NTP server reference involves some trade offs. It can be a deep rabbit hole with seemingly no bottom if you just start studying spec sheets.

I believe the first step is define the role of the server and needed vs desired accuracy on your real network. My goal was 1 millisecond time with sub 500 microsecond jitter / wander. Remember that network traffic and congestion in network devices like switches can have impacts greater than instability of the time source. So some extended ping testing under varying network conditions can be helpful to get an idea of network induced error. Looking at standard deviation of ping time is one good indication of problems to be solved before proceeding.

Assuming your goals are relatively modest like mine and the network checks out OK, the next step is finding a suitable GPS receiver.

A few things we are looking for here are: Standard NMEA 183 output, 1 PPS output pulse and serial rather than USB interface. Provision for an external antenna is a great feature and may be a requirement depending on the situation. Although a USB interface may sound good, because of the way communication is achieved by asynchronous polling of the host device, a lot of uncorrectable variability occurs compared to old-fashioned RS232 serial, even at low baud rates like 4800. I haven’t actually evaluated USB and what this means from a practical standpoint, however. The PFSense document on NTP does not recommend USB.

GPS receivers can be divided into two broad classes with some crossover. Most receivers are position/navigation optimized devices. But there are those that are designed specifically for timing applications. Navigational units need to deal with triangulation from multiple sats at different elevations and also with motion. Their algorithms have location parameters as their priority which slightly degrades timing accuracy. Timing GPS receivers are different. They can go into a “position hold” mode at previously established coordinates and even look at just one satellite to achieve very low jitter on the 1 pps pulse. The internal circuits including the clock oscillator and those that process the pulse are also optimized so that 10-15 nanosecond specs are typical of this class. About 10 to 100 times better than your average navigation GPS. These are probably overkill for a home lab though. They tend to be expensive ‘niche” devices. Another class of receivers from the innovative U-Blox people have part numbers that end in “T” like 5T 0r 6T. The T stands for timing, and they are a hybrid design that combine good positional performance, but can go into position hold and behave as very accurate timing receivers. They use an internal TCXO rather than a regular crystal oscillator for better hold-over stability.

Thus far, I have evaluated three receivers and compared their relative NTP performance on PFSense. One was already in stock and the other two were purchased.

The first RX was a CSI Mini-Max, a marine oriented unit with WAAS and differential GPS capability, but no pps output. The second was a Garmin GPS18x-LVC, a hockey-puck style OEM 12 ch receiver with a built-in patch antenna, WAAS, and PPS pulse output. The third was an inexpensive U-Blox 6M module modified to generate PPS from it’s blinking LED and it’s 3.3V logic i/o converted to RS232 by way of a Max3232.

All performed well enough in a home lab, for all but the most critical applications. That said, the addition of the 1 pps pulse makes a significant improvement. See the graph below. It shows the Garmin unit running without the PPS signal line connected in the first portion, and the effect of connecting the PPS line toward the mid-portion of the graph. Jitter, wander and dispersion all decrease dramatically.

Adding PPS to NMEA Data Stream

The Garmin 18x is a very good performer. It had adequate sensitivity to pick up 8-10 sats indoors. A real achievement with the foil-backed insulation in the ceiling. It’s also very convenient to use. It has standard RS232 serial output, and just needs 5V at about 60 mA; that can be robbed from a nearby USB port. I have it sitting on the top of my 6ft rack staring up towards the roof. It also has a handy magnet on the bottom to hold it to ferrous metal.

Garmin GPS18x-LVC
Garmin 18x NTP Performance over 1 hour

Finally, the little U-Blox 6M also worked very well. Maybe just a bit more jitter at times than the Garmin, but still well within my design goals. Again, this was indoors. It was eventually assembled in a 3D printed PETG case that can be mounted outdoors with a 20M length of shielded Cat5 cable carrying both the serial data and 5v power. A modified RJ45 to DB9 adapter inserts the power at the computer end of the cable. The base has screw holes to fasten to a flat surface. The UBlox people have a very nice piece of software (Windows only) called U-Center that allow many, many different parameters to be changed and saved to flash in these modules. I merely set the baud rate, turned on the PPS LED and set it’s duty cycle, but there are a lot more options to explore here. I might have missed something really good…

Neo 6M Stats
Mini Water Tower with UBlox 6M inside
Cat5 to DB9 data and power

Next NTP experiments may be using a Raspberry Pi4. I also have a U-Blox LEA-5T based surplus timing board coming on a slow boat from China (literally) It’s a GPS/GNSS module optimized for timing applications. It has the fixed position mode available and can use a single satellite. Should be interesting to compare and program with U-Center. More fun to come.

Dave, K7DMK

Building a GPS Referenced NTP Server Part 2

The kernel used in Linux and BSD operating systems has historically derived it’s timing accuracy from an oscillator, normally an inexpensive crystal oscillator present on the system board. From this oscillator, all the system clocks needed for the CPU and various buses are generated. In addition, most computers have a real time clock chip (RTC) powered by a battery that keeps time in non-volatile ram. This clock is often synchronized with NTP and OS time as a start-up process. Early NTP clocks concentrated efforts solely on providing more accurate and stable system oscillators.

More recently, many Unix-like kernels have included a mechanism for disciplining it’s timing by an outside reference. Most modern implementations of Linux and BSD have this feature. This allows very fine adjustment of kernel timing and subsequent time keeping without having to make hardware modifications to the system board. The NTP server software, likewise has an internal timing module generally based on a modeled PLL oscillator, that allows external references of both NMEA time data and precise 1 pps time pulses to be applied. The combination of kernel disciplining and external references for NTP allow very accurate time information to be served.

PPS Correction

Two interesting software distributions that can used to create Swiss-army knife network appliances for firewalls/UTM’s, routers and VPN gateways are PFSense and OPNSense. Both have the ability to provide a highly accurate NTP time server, when locked to an external reference, in addition to many other network tasks. So in this case, a dedicated computer is not needed exclusively for a NTP server.

In the first experiment, an existing installation of PFSense currently acting as a firewall and VPN gateway was modified to add an accurate, low latency NTP server to the LAN. The PFSense software is running on a small rack mount SuperMicro mini-server with a dual core D525 Atom CPU. It’s an ideal machine for this purpose since it has an unused serial port and requires less than 25 watts of power to operate. It’s LAN side is already connected to the network by a Gigabit NIC. The NTP server will be setup to allow time requests on the LAN port only.

In part 3, we will discuss the considerations of selecting an appropriate GPS external reference, and the kind of results one might expect with various classes of GPS receivers.

Dave, K7DMK

Building a GPS Referenced NTP Server Part 1

NTP is an old, but still very useful time transfer protocol. The mechanism uses NTP client software on a host computer that “asks” for time info, and a NTP server somewhere out on the network that sends out the current time and date in a specific format. “Out on the network ” usually means the Internet. Usually port 123 is used. There are many existing public NTP servers on the Internet and many are incorporated into open pools like that permit a generic url to be specified rather than a particular IP address.

So why build a NTP server and put it on your local network? If very accurate time is needed for your application, such as scientific experiments, time stamps in synced databases or radio systems, etc, a local time server can be very useful. Because of the variable latency of WAN based servers, really accurate time is hard to achieve via the Internet . The actual network time delay accessing a Internet server has some compensation in the protocol, but it’s the unpredictable jitter (phase noise being a model) and wander (random noise) due to the vulgarities of the Internet, that is not correctable.

Time servers are described by their “Stratum level” determined by their source of time reference, and also how far they are removed from the primary reference. A Stratum 1 NTP server gets it’s time from a so called primary time reference called a Stratum 0 (zero) source. So by definition, there is no Stratum zero NTP server, since the clock does not connect directly to a network. Twenty years ago, building a Stratum 1 NTP server meant using something like a very expensive cesium clock, or perhaps one based on a rubidium oscillator. Today, GPS can provide that reference with comparable specs, but as usual, the devil is in the details. More on that later.

Another time server that connects to the Stratum 1 time server to get it’s time to forward, becomes a Stratum 2 server by this convention. Still another NTP server that connects to the second server would become a Stratum 3 server. Each time you are farther removed from the primary time source, the Stratum level goes up. The accuracy and uncertainty gets worse each time because of the expected jitter in the network connection between them is accumulating.

Not long ago, establishing a true Stratum 1 time server on one’s network was an expensive proposition. Today we have several relatively inexpensive options to choose from.

We will be exploring a couple of these options over the next few weeks.

Dave, K7DMK

K7EVR Digital Amateur Radio