Application Note – 40
NTP (Network Time Protocol) “Hacked” Especially for YOU!

Introduction
Some time ago (2012 actually) we provided a paper discussing the virtues of NTP (Network Time Protocol) versus PT P (Precision Time Protocol).
In contrast, this brief paper focuses exclusively on the use of NTP, which is to date still the most widely used Ethernet time protocol for synchronization of local clocks. This probably because still for the majority of regular users, a few milli seconds is far more precise than they need for absolute time.
In a departure from the norm however, this paper discusses a somewhat different, although fairly common, requirement, where the emphasis is not on synchronizing to UTC (the international time standard, Universal Time Coordinated, used as the basis for providing NTP time) but rather on synchronizing a number of devices to the same time, regardless of what that absolute time is.
Review of NTP
A quick review of the NTP protocol (lifted from our earlier paper) is shown below:
“The NTP concept basically consists of two elements, an NTP server and an NTP client.
An NTP server is a device that acquires time (typically from the Global Positioning Satellite system) and outputs NTP using TCP/IP (either on request or at regular preset intervals) on Ethernet port 123. The output packet is described below and includes information regarding the accuracy/origin of the time being transmitted as well as the time. The time is always based on UTC (Universal Time Coordinated – the worldwide standard for time) and is converted to NTP seconds/milliseconds. In many cases where time is directly acquired by the NTP server (e.g. from the GPS system) the server is actually an SNTP server, where the “S” stands for Simple. The NTP model is less sophisticated however the protocol is identical.
An NTP client receives the transmitted NTP packet, on Ethernet port 123, and converts back from NTP seconds to UTC and often in turn to “local” time. There is no facility within NTP to transmit local time offsets or daylight savings time.
The conversion to and from NTP seconds may seem strange at first, however it is clearly important that all NTP servers and NTP clients refer to the same timescale, and the background of the NTP second is connected to the commencement of UTC at 00:00 hours on January 1, 1972. At that time it was decided to set the NTP second to a value of 2,272,060,800.0 which meant that extrapolating back, the NTP second was 0 (i.e. started) at 00:00 hours on January 1, 1900.
NTP time is represented by a 64 bit unsigned integer field. The integer part of NTP time (i.e. whole seconds) is contained within the first 32 bits and therefore will “roll over” approximately every 136 years (232 = 4294967296 seconds which equates to around 136.19 years). This means that if still in use, NTP will “roll over” some time in 2036. The fractional part of NTP is contained within the second 32 bits which actually gives a resolution of 1/232 or approximately 0.23 nano seconds – more than adequate for most applications, especially when considering that very few primary clocks provide time to an accuracy of better than a few nano seconds.”
Non UTC Synchronized Application Requirement
You may well ask “Why anyone would want to do that?”, and it’s not an unreasonable question. The answer is that for certain applications, access to UTC either via some kind of GPS (satellite) receiver or even the world wide web, is not only unnecessary but in many cases undesirable, as the environment within which equipment to be synchronized is being used needs to be carefully isolated from the “outside” world. So, the requirement is merely to synchronize each item of equipment to the other items within the sealed environment, possibly to some quite arbitrary time reference, but in any case not to UTC.
The easiest way to accomplish this is by use of NTP sent from a standard commercially available NTP server such as the ptf 3203A, however In scenarios such as described, one of the “features” of NTP can in this case be a source of some frustration. The particular feature to which I am referring can be best explained by reviewing the diagrammatic representation of the protocol flags shown below:
The NTP indicators are contained in a 32 bit word as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |MODE | STRATUM | POLL | PRECISION |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For a detailed description of all of the fields, please refer to our earlier paper at : http://ptfinc.com/download/649/
For this paper, we are only interested in the “Stratum” flags as described below:
STRATUM = an eight-bit unsigned integer indicating the stratum level of the local clock, with values defined as follows:
Stratum Meaning
———————————————-
0 unspecified or unavailable
1 primary reference (e.g., radio clock)
2-15 secondary reference (via NTP or SNTP)
16-255 reserved
The reason we are interested in the Stratum, is that the stratum value is more often than not used in NTP clients, (the part of the protocol that resides in the various pieces of equipment to be synchronized) to determine whether or not to use the incoming (from the NTP server) NTP message in order to set time within the equipment. If the incoming message indicates a stratum level of anything less than 1, it is highly probable that the client will reject the message and not synchronize.
For applications such as this, to avoid the necessity of coming up with some alternative (probably expensive) system to synchronize the equipment, Precise Time and Frequency, Inc. has developed a special software option (NTPS) that forces the Stratum flag in the NTP message to a 1, indicating that the message is coming from a primary reference clock.
This “hack” has proven to be very effective in many applications, and whilst it would not be recommended for general use, it is definitely a way to circumvent what would otherwise be a difficult issue.
For further information on NTP servers, or the latest frequency and time instrumentation, please contact: