| |
KF5JRV > TECH 30.04.16 12:32l 131 Lines 7295 Bytes #999 (0) @ WW
BID : 2251_KF5JRV
Read: GUEST
Subj: Network Time Protocal
Path: IZ3LSV<IW0QNL<JH4XSY<JE7YGF<N9PMO<N0KFQ<KF5JRV
Sent: 160430/1126Z 2251@KF5JRV.#NWAR.AR.USA.NA BPQK1.4.65
Network Time Protocol
The Network Time Protocol (NTP) is the most commonly used Internet time
protocol, and the one that provides the best performance. Large
computers and workstations often include NTP software with their
operating systems. The client software runs continuously as a background
task that periodically gets updates from one or more servers. The
client software ignores responses from servers that appear to be sending
the wrong time, and averages the results from those that
appear to be correct.
Many of the available NTP software clients for personal computers
don't do any averaging at all. Instead, they make a single timing
request to a signal server (just like a Daytime or Time client) and then
use this information to set their computer's clock. The proper name
for this type of client is SNTP (Simple Network Time Protocol).
The NIST servers listen for a NTP request on port 123, and respond by
sending a udp/ip data packet in the NTP format. The data packet includes
a 64-bit timestamp containing the time in UTC seconds since January 1,
1900 with a resolution of 200 ps.
Most of the NIST time servers do not require any authentication when
requesting the time in NTP format, and no keys or passwords are needed
to use this service. In addition to this standard NTP service (which
will not be modified), we have begun testing an authenticated version of
NTP using a single time server that implements the symmetric key
encryption method defined in the NTP documentation. In order to use
this server, you must apply to NIST for an encryption key, which will
be linked to the network address of your system. This service is being
offered on an experimental basis only, and it may not be continued
after the initial testing period. For more details, please see the
authenticated ntp description. Daytime Protocol (RFC-867)
This protocol is widely used by small computers running MS-DOS and
similar operating systems. The server listens on port 13, and responds
to requests in either tcp/ip or udp/ip formats. The standard does not
specify an exact format for the Daytime Protocol, but requires that
the time is sent using standard ASCII characters. NIST chose a time
code format similar to the one used by its dial-up Automated Computer
Time Service (ACTS), as shown below:
JJJJJ YR-MO-DA HH:MM:SS TT L H msADV UTC(NIST) OTM
where:
JJJJJ is the Modified Julian Date (MJD). The MJD has a starting
point of midnight on November 17, 1858. You can obtain the MJD by
subtracting exactly 2 400 000.5 days from the Julian Date, which is
an integer day number obtained by counting days from the starting
point of noon on 1 January 4713 B.C. (Julian Day zero).
YR-MO-DA is the date. It shows the last two digits of the year, the
month, and the current day of month.
HH:MM:SS is the time in hours, minutes, and seconds. The time
is always sent as Coordinated Universal Time (UTC). An offset needs
to be applied to UTC to obtain local time. For example, Mountain Time
in the U. S. is 7 hours behind UTC during Standard Time, and 6 hours
behind UTC during Daylight Saving Time.
TT is a two digit code (00 to 99) that indicates whether the United
States is on Standard Time (ST) or Daylight Saving Time (DST). It also
indicates when ST or DST is approaching. This code is set to 00 when
ST is in effect, or to 50 when DST is in effect. During the month in
which the time change actually occurs, this number will decrement every
day until the change occurs. For example, during the month of November,
the U.S. changes from DST to ST. On November 1, the number will change
from 50 to the actual number of days until the time change. It will
decrement by 1 every day until the change occurs at 2 a.m. local time
when the value is 1. Likewise, the spring change is at 2 a.m. local time
when the value reaches 51.
L is a one-digit code that indicates whether a leap second will be
added or subtracted at midnight on the last day of the current month. If
the code is 0, no leap second will occur this month. If the code is 1, a
positive leap second will be added at the end of the month. This means
that the last minute of the month will contain 61 seconds instead of 60.
If the code is 2, a second will be deleted on the last day of the month.
Leap seconds occur at a rate of about one per year. They are used to
correct for irregularity in the earth's rotation. The correction is made
just before midnight UTC (not local time).
H is a health digit that indicates the health of the server. If H = 0,
the server is healthy. If H = 1, then the server is operating properly
but its time may be in error by up to 5 seconds. This state should change
to fully healthy within 10 minutes. If H = 2, then the server is operating
properly but its time is known to be wrong by more than 5 seconds. If H = 3,
then a hardware or software failure has occurred and the amount of the time
error is unknown. If H = 4 the system is operating in a special maintenance
mode and both its accuracy and its response time may be degraded. This value
is not used for production servers except in special circumstances. The
transmitted time will still be correct to within ñ1 second in this mode.
msADV displays the number of milliseconds that NIST advances the time
code to partially compensate for network delays. The advance is currently
set to 50.0 milliseconds.
The label UTC(NIST) is contained in every time code. It indicates that
you are receiving Coordinated Universal Time (UTC) from the National Institute
of Standards and Technology (NIST).
OTM (on-time marker) is an asterisk (*). The time values sent by the
time code refer to the arrival time of the OTM. In other words, if the time
code says it is 12:45:45, this means it is 12:45:45 when the OTM arrives.
Time Protocol (RFC-868)
This simple protocol is now used by only about 1% of ITS customers. It
returns a 32-bit unformatted binary number that represents the time in UTC
seconds since January 1, 1900. The server listens for Time Protocol requests
on port 37, and responds in either tcp/ip or udp/ip formats. Conversion to
local time (if necessary) is the responsibility of the client program. The
32-bit binary format can represent times over a span of about 136 years
with a resolution of 1 second. There is no provision for increasing the
resolution or increasing the range of years.
The strength of the time protocol is its simplicity. Since many computers
keep time internally as the number of seconds since January 1, 1970 (or
another date), converting the received time to the necessary format is
often a simple matter of binary arithmetic. However, the format does not
allow any additional information to be transmitted, such as advance
notification of leap seconds or daylight saving time, or information about
the health of the server.
However, the time format (as specified in RFC-868) has poor error-handling
capabilities in general, and many of the client programs that use this
format are poorly written and may not handle network errors properly.
Therefore users are strongly encouraged to switch to the Network Time
Protocol (NTP), which is more robust and provides greater accuracy.
Read previous mail | Read next mail
| |
