SNTP Time Class
Written by Harry Fairhead   
Sunday, 01 September 2024
Article Index
SNTP Time Class
The Time Commands
The SNTP Class
Getting the Time
Complete Listing

The Time Commands

The first 32-bit word of the packet is an information and command word and from the specification it seems to be the only part of the structure you need to set before sending the request.

 

command

The first word

 

Most of the other fields are for return data.

The first byte is most important. The first two bits carry leap second information and can mostly be ignored.

LI
00   0  no warning
01   1  last minute has 61 seconds
10   2  last minute has 59 seconds)
11   3  alarm condition (clock not synchronized)

The next three bits specify the SNTP version and should be set to 1 by a client so that the request will be processed by almost any server.

The final three bits specify what should happen, i.e. the state or Mode:

Mode

0 reserved
1   symmetric active
2   symmetric passive
3   client
4   server
5   broadcast
6   reserved for NTP control message
7   reserved for private use

Mode should be set to 3 for a client request and the server will set it to 4 in the response packet.

The remaining three bytes provide information on the server's time keeper. Stratum gives the level of time precision:

Stratum

0      unspecified or unavailable
1      primary reference (e.g., radio clock)
2-255  secondary reference (via NTP or SNTP)

Poll gives the minimum time between packets that the server can send.

This is a signed integer giving the power nearest power of 2 in seconds. For example a value of 0 indicates 1 second, a value of 1 indicates 4 seconds, -1 indicates 1/2 second and so on.

Precision is an eight-bit signed integer giving the clock's precision again as a power of 2 in seconds.

The following three words give the root delay, i.e. the round trip delay to the server's primary time source; the root dispersion, i.e. the relative error of the server's time against the primary time source.

Both of these are fixed point signed values with the binary point between bits 15 and 16.

Reference identifier, i.e. a four-byte ASCII code specifying the type of clock used as the standard.

The only problem with the reference identifier is that it isn't specified in the standard but for stratum 1 servers you can look out for

ATOM = atomic clock,

PPS= Precision Pulse Source

GPS= Global Positioning Satellite

and so on.

Radio clocks often quote their radio call sign. For a secondary reference the four bytes are often the TCP/IP address of the primary server.

 

The time stamps

When you get the time packet back it contains four timestamps that can be used to improve the estimate of the current time:

  • Reference Time Stamp (RefTS) – Time the server’s clock was last set

  • Transmit Time Stamp (TTS) - Time at the server when the packet left

  • Originate Time Stamp (OTS) - Time you sent the request packet

  • Receive Time Stamp (RTS) - Time the server received the packet.

These values can be used to estimate the round trip time and correct the final time to the last few tenths of a millisecond.

The reason is that the time that you get back in Transmit Time Stamp (TTS) was the time at the server when the packet left the server. It takes time for the packet to reach you and this has to be taken into account.

The Originate Time Stamp (OTS), i.e. the time you sent the request packet and the Receive Time Stamp (RTS), i.e. the time the server received the packet, and time the packet actually arrived can be used to estimate the round trip time and correct the final time to the last few tenths of a millisecond.

In practice you can ignore all of this unless you really are trying for high accuracy. All that matters is the TTS which contains the time as measured at the server when the packet was transmitted – this will be accurate to a few milliseconds unless the conditions on the Internet are so bad that you would be well advised to use an alternative server.

So it looks as if we can ignore all the time stamps in the requesting package and only look at the TTS value in the return package.

The only problem is that some servers ignore packets with unreasonable values of OTS in the requesting packet, but when making the first request there is no reasonable way to set this value.

<ASIN:B00OD4LR06>

<ASIN:B09FTLPTP9>

 



Last Updated ( Sunday, 01 September 2024 )