[Cerowrt-devel] cerowrt 3.3.8-17: nice latency improvements, some issues with bind
marchon at gmail.com
Mon Aug 20 16:41:48 EDT 2012
Check and set the time by syncing to NTP Servers - not user supplied times
if the network
is available. to see if they have set times > those set by NTP Server
The global address *time.nist.gov* is resolved to all of the server
addresses below in a round-robin sequence to equalize the load across all
of the servers.
Network Time Protocol (RFC-1305)
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
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
as shown below:
*JJJJJ YR-MO-DA HH:MM:SS TT L H msADV UTC(NIST) OTM*
- 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.
On Mon, Aug 20, 2012 at 4:16 PM, <david at lang.hm> wrote:
> On Sat, 18 Aug 2012, Michael Richardson wrote:
> If we are writing the file system such that time can really never go
>> backwards, then we are pretty much immune to most replay attacks
> If time cannot go backwards, what do you do if someone accidently sets the
> time in the future?
> David Lang
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.**bufferbloat.net<Cerowrt-devel at lists.bufferbloat.net>
P THINK BEFORE PRINTING: is it really necessary?
This e-mail and its attachments are confidential and solely for the
intended addressee(s). Do not share or use them without approval. If
received in error, contact the sender
and delete them.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cerowrt-devel