The modern military battlefield and infrastructure support have become extraordinarily dependent on precise time and frequency distribution for radio communication and long-haul fiber and satellite communication systems. Precise synchronization is necessary for SINCGARS frequency-hopping radios and Synchronous Optical Networks (SONETs) and satellite links. Previously, provisions for precision time and frequency sources was on a system-by-system basis with no urgent need for standardization. However, recent efforts in the U.S. military and NATO (North Atlantic
Treaty Organization) allies [7] have identified a number of standard time and frequency issues so that the various domestic and international military units can interoperate with equipment from different suppliers in different countries. The standards issues have evolved over many years in the precise time and time interval (PTTI) community [7].
There are currently two families of standard interfaces, the MIL-STD 188125 standard [8] used by the U.S. Have Quick radio system and the STANAG 4330 standard [9] used by the United States and its NATO allies. Certain versions of these standards can interoperate. Both include a frequency interface at 5 MHz or some multiple, which is not of further interest here. Both include a precision time code that might be a useful source to discipline a computer clock, such as might be found on an air force aircraft or navy vessel. The timecode is usually transmitted using Manchester encoding with a pulse width of 60 ]s, resulting in a bit rate of about 16.7 kb/s. The on-time epoch is defined by a PPS signal transmitted on a dedicated wire. The current time at the on-time epoch is transmitted as a string of octets, where each octet consists of a four-bit BCD digit preceded by a four-bit checksum of the octet. Each octet represents a code word from a Hamming 8,4 code, which has distance 4 and thus can correct a single-bit error and detect two-bit errors.
The timecode formats used by in Have Quick and STANAG 4330 are shown in Figure 15.9. The timecode is preceded by a start-of-message (SOM) octet and followed in some formats by an end-of-message (EOM) octet. The Have Quick I format includes the hours, minutes, and seconds, each in two octets each in that order. The Have Quick II format appends the day of the year in three octets followed by the year in two octets. The STANAG 4330 and Extended Have Quick (XHQ) format appends a time figure of merit (FOM) in one octet plus seven additional octets, including a control command and leap second warning.
FIGURE 15.9
Have Quick and STANAG 4330 timecode formats.
Parting Shots
It may be interesting to speculate on how NTP could make use of hard-stamps, perhaps in a way very similar to IEEE 1588, in which an event such as the passage of the Ethernet SOF octet latches an internal NIC counter. In the scheme proposed in this topic, the NTP NIC is much simpler than the PTP NIC; the counter need not be disciplined and need not run at any particular rate. A timestamp is captured for every transmitted and received packet and buffered in an FIFO until the driver can read them.
Since timestamps are captured for every packet transmitted and received, there is no need to parse the packet itself or change it in any way. The time-stamps are conveyed to the NTP program by one means or another. Receive timestamps could be appended to the packet data mbuf chain and eventually placed in the receiver buffer or socket storage. Transmit timestamps could be inserted in the transmit buffer to be returned to the NTP program as the buffer storage is reclaimed.
The transmit case is not as easy as it might seem. In PCNET NICs, the transmit buffer is ordinarily reclaimed when the last bit is DMAed to the FIFO, but it has to hang around until the associated timestamp is captured. However, there might be other Ethernet frames in the FIFO ahead of this frame. Therefore, the driver has to keep track of the number of frames in the FIFO and match them with the entries in the timestamp FIFO.
Note that the NTP NIC counter is not necessarily syntonic with the system clock or even other NTP NIC counters, and the need exists to convert the NIC time to system clock time format. But, this is the same issue studied in Section 15.2, and the same techniques apply. At intervals something less than 1 s, the NIC driver updates the structure holding the last NIC clock and system clock and trims the K multiplier. The NIC clock is read and converted to system format as the driver extracts the entries from the timestamp FIFO.
In principle, this scheme could deliver timestamps as precise as PTP, assuming the NIC clock is fast enough. However, the weakest link in this scheme is that the master reference source is the commodity compute clock oscillator and operating system. A good guess is that this scheme could do as well as the PPS discipline, which has a nominal jitter on the order of a few microseconds.
