clockspeed vs ntp
Joe
any comments about the advantage of ntp over clockspeed. I've tried both
and I really like the approach of clockspeed. Rather than continually reset
the clock on the computers in my network, clockspeed calibrates the clock
on each system against a stratum 2 time server. Over time the accuracy of
the local computer clock converges and the accuracy is quite astounding.
Why not use clockspeed instead??
--------------------
JoeS
joes at mad dot scientist dot com
Joe
Joe wrote:
--
--------------------
Joe Sotham
David Schwartz
> Why not use clockspeed instead??
Because if all my clocks were .2 seconds off, I'd never know in what
order events ocurred across my network.
DS
David Woolley
From: "Joe <see...@no.spam.ca>" <> (bogus address) wrote:
> any comments about the advantage of ntp over clockspeed. I've tried both
> and I really like the approach of clockspeed. Rather than continually reset
> the clock on the computers in my network, clockspeed calibrates the clock
> on each system against a stratum 2 time server. Over time the accuracy of
> the local computer clock converges and the accuracy is quite astounding.
This appears to describe how ntpd works, except that ntpd uses multiple
timeservers at multiple strata, using various algorithms to determine
the most reliable of those servers and then to get the most reliable
estimate of the time from those servers.
Incidentally, unless "stratum 2" is an NTP stratum, how do the stratum
2 servers synchronise with their stratum 1 ones, if "clockspeed" will
not synchronise to stratum 1 servers. If it is an NTP stratum, then
clockspeed must be an implementation of SNTP, or a partial implementation
of NTP, so you are comparing NTP with a subset of NTP, rather than NTP
with a different approach. It can't be a full implementation of NTP
if it only permits one server and that must be at stratum 2.
For the avoidance of doubt, ntpd maintains the time by adjusting the
effective clock frequency, not by stepping the time. Where the kernel
permits it, it controls the time accumulated for each hardware tick to
a high precision. Otherwise, it runs the clock faster or slower for part
of each four seconds cycle, so that the average clock speed is adjusted.
In both cases, it converges onto an estimate of the ideal clock frequency
correction, and tracks that as the hardware clock rate changes.
Stepping the time is a last resort when the time error is unreasonable.
PS You failed to say what platforms "clockspeed" runs on.
PPS Looking at the rather terse description on
http://cr.yp.to/clockspeed.html, it seems that clockspeed doesn't
synchronise to servers at all but simply applies a correction to the
software clock (obtained in a rather round about way) based on two
measurements of the skew. You can do the same on Linux, which seems
the primary target, by using ntpdate to read the skew and ntptime to
set the kernel clock frequency.
The web page claims 0.21 seconds in about 3 months. In my experience,
this is only possible with good air conditioning, and even then may
well have significant short term variation. Using ntptime to set the
frequency on a home desk top (no air condition, although some control
through central heating in the winter, I get between better than 100ms a
week to just over a second. (Using the sound driver causes lost ticks
and a significant error - possibly actually due to under/overrun kprintf
messages.)
As I understand it, the roundabout way of doing the correction involves
using a diagnostic counter in the CPU as an alternative high resolution
time source, whereas the NTP kernel PLL simply uses a rate multiplier
approach.
David L. Mills
Excellent reply. Another approach works with Linux, FreeBSD, Solaris and
Alpha (recompile kernel with MICRO_TIME defined). Build the NTPv4
distribution with kernel discipline enabled. This requires the
/usr/include/sys/timex.h file to be present, which should be the case
with these systems. Run stock ntpd for a day and let it settle down the
clock frequency, which is remembered in the kernel. Quit the daemon and
let the kernel sail on with remembered frequency. Run the daemon in
ntpdate mode (ntpd -q) at reboot and once a day after that to trim the
residual. Typical behavior at room temperature is 5-20 milliseconds per
day.
Dave
Matthias Andree
> Why not use clockspeed instead??
clockspeed does not synchronize, but just account for the clock drift.
--
Matthias Andree
Outlook (Express) users: press Ctrl+F3 for the full source code of this post.
begin dont_click_this_virus.exe
end
D. J. Bernstein
of using xntpd:
* I didn't trust xntpd's security. People subsequently discovered
that xntpd was vulnerable to a remote root exploit. I still don't
trust xntpd's security.
* I don't like xntpd's bogus interpretation of UNIX time. It doesn't
give accurate local-time displays. It's also incompatible with the
huge base of code that adds and subtracts time values to measure
real-time intervals. The errors occur only around leap seconds, but
they're still thoroughly unprofessional.
Of course, xntpd can do many things that clockspeed can't, such as merge
responses from several NTP servers.
Matthias Andree <matthia...@gmx.de> wrote:
> clockspeed does not synchronize,
Sure it does, every time you run sntpclock. You can run sntpclock from
cron if you want. The next version of clockspeed will have a simpler way
to set this up.
---Dan
Matthias Andree
> Of course, xntpd can do many things that clockspeed can't, such as merge
> responses from several NTP servers.
...or synchronize to network broadcasts which can e. g. be sent by some
router types or -- [x]ntpd.
Does sntpclock compensate for network latency?
Does clockspeed work on machines that crash or that are shut down during
the night without using the full-resynchronization scheme around
sntpclock? xntpd which has servers configured with iburst option is
really useful for those scenarios.
> Matthias Andree <matthia...@gmx.de> wrote:
> > clockspeed does not synchronize,
>
> Sure it does, every time you run sntpclock. You can run sntpclock from
> cron if you want. The next version of clockspeed will have a simpler way
> to set this up.
Yes, but that "NTP client" propery is not clockspeed's, but
sntpclock's.
D. J. Bernstein
> Does sntpclock compensate for network latency?
Of course.
> Does clockspeed work on machines that crash or that are shut down
> during the night without using the full-resynchronization scheme
> around sntpclock?
Yes. The best estimate of the clock speed is saved on disk. A single
sntpclock reading after boot is enough to return to normal behavior.
> > > clockspeed does not synchronize,
> > Sure it does, every time you run sntpclock. You can run sntpclock from
> > cron if you want. The next version of clockspeed will have a simpler way
> > to set this up.
> Yes, but that "NTP client" propery is not clockspeed's, but
> sntpclock's.
Silly distinction. sntpclock is part of the clockspeed package. The
sntpclock program is designed to work with the clockspeed program.
---Dan
David L. Mills
I'm delighted you decided to write your own client and would be even
more thrilled if your implementatino conformed to RFC-2030 or RFC-1305
as appropriate. That would make a whole bunch of folks real happy.
However, I should clarify a couple of points you raise. There was in
fact a security vulnerability, although a really remote one, which had
existed for over a decade and was recently fixed in NTPv4. As we do not
maintain NTPv3 here, I can't verify whether the version folks use has
been patched or not. As for your plaint that NTP does not maintain an
accurate local time display, right on dude. NTP and Unix run only in UTC
and local time offsets are added by library routines. Your
implementation may do otherwise, but be prepared for interesting
features in India, Saudi Arabia and Australia, among others.
Having said that and in view of your related comments on NTP time
intervals, your message caused me to reflect on an interesting addition
to the NTP protocol machine. This would be provisions to include the
local time offset from Greenwich in the NTP packet. That's a wonderful
idea and I thank you for suggesting it.
However, I do take exception to your claim about xntpd's bogus
interpretation of Unix time and that errors occur around leap seconds. I
would very much like you to expand on that comment, even if the
implementation really is, in your words, totally unprofessional. Did you
observe incorrect behavior at some previous leap event? I have
personally watched every leap event since 1982 and can cite chapter and
verse upon each occasion. Surely, in the early years funny little things
did happen somewhere in the then Internet. It's hard to test something
when the event happens only every 18 months.
Probably until the late 80s, the usual problem was the code didn't leap
because the radio transmitters, receivers or both did not encode or
decode advance leap information and the leap bits had to be set at the
primary servers by hand. Setting by hand became impractical when the
effort to update all these servers became unbearable. So, you might have
noticed some servers and clients leaped while others did not. That's why
there is a little bit of madness in the code that takes a vote of the
leap bits and leaps only if half or more of the immediate upstream
servers leap bits are set. This of course is not very pretty, and you
should be able to improve the algorithm. If you can reveal it to
hac...@ntp.org, we would be happy to retrofit in the current code.
The real problem with leap implementation is that it must be done in the
kernel. The current precision time kernels in Linux, FreeBSD, Tru64 and
Solaris include a special state machine designed to do exactly that. The
NTPv4 deamon arms it on the day of the leap and the state machine does
the rest. This code has worked exactly as intended for the last several
leap events at least since 1995.
You raise the issue about the "huge base of code that adds and subtracts
time values to measure real-time intervals". Surely, NTP time intervals,
Unix time intervals and Excel time intervals spanning one or more leap
events are in error by that number of leap seconds. Also, time intervals
before 1972 had no leap events and future leap event predictions are
conjectures at best. Timekeepers have traditionally ignored the usually
minor errors these intervals might contain, but you rightly point out
that small intervals spanning a leap event might well have unacceptable
error. I hope your implementation squarely addresses that issue,
especially the manner in which the system clock is disciplined in
response. The current model runs the clock slow for a little over a
second in order to insert the second. This is really ugly and you should
be able to come up with a better way.
Now the other shoe drops. If you really do need precision interval
measurements apanning one or more leap events, the current NTPv4
development version has a feature designed just for fastitious
timekeepers like you. This is in the form of a table of historic leap
second insertions ultimately derived from NIST data and automatically
distributed from servers to clients using the autokey protocol. While at
the moment there is no convenient way to provide this table directly to
an application, the current TAI offset is available with a new syscall
now in FreeBSD and Linux.
Now, your implementation could fetch the leapseconds table from a NIST
time server near you and incorporate it in your design, thus avoiding
the messy autokey protocol and attendent public key cryptography. It
should not be a big problem to make this table available to applications
that need it, but it would be real helpful if you could document your
proposed interface as an Internet Draft.
Keep up the good work. If you wuld like, we would be happy to provide a
launching rack for your distribution at ntp.org.
Dave
David L. Mills
Geeze, I don't want to confetti this list, but I should point out that
xntpd does not have the iburst feature. You need NTPv4 for that.
Dave
D. J. Bernstein
> NTP and Unix run only in UTC
With my NTP implementation and Olson's popular tz library in right mode,
UNIX time
* is a clean, monotonic second counter,
* produces accurate UTC displays,
* produces accurate local-time displays, and
* is consistent with the massive installed base of code that adds and
subtracts time values to measure real-time intervals.
Your NTP implementation, however, sets UNIX time in a way that
* throws away information,
* is not monotonic,
* produces inaccurate UTC displays,
* produces inaccurate local-time displays,
* is not consistent with the tz library in right mode, and
* is not consistent with that massive installed base of code.
As I said, the errors in clock displays and real-time measurements occur
only around leap seconds, but they're still thoroughly unprofessional.
---Dan
David L. Mills
Good show; I love it. Where did you get the idea that NTP time is "not
monotonic"? You may have not been keenly observant of the NTP clock
discipline, but also the NTP kernel time discipline. If you have
observations to the contrary, you are seriously challenged to reveal
them. I do not challenge in any way your observations, but I would very
much like to understand their import and to correct what might be
misunderstandings on my part.
You do understand the model that NTP keeps only UTC time; if not, you
should reconsider the issues involved, especially for those lost souls
in western Australia and India. As for accurate UTC displays; geeze, you
have no faith in the ntpq displays that show typical deviations less
than a millisecond. I do admit occasional exceptions as noted at
www.eecis.udel.edu/~mills/ntp.htm, but such is modern life. As for the
massive installed base of code that adds and substracts time values, I
thought I had answered that in my previous message, but apparently you
were not listening. I have to conclude you have another agenda to favor
some project of yours that is opaque from here. All I can say is best
regards and have a good life.
I am finished with this thread. Related observations should start a new
one.
Dave
D. J. Bernstein
say it was, when the actual time was 1998-12-31 23:59:60.047 UTC?
1999-01-01 00:00:00.047 UTC is _wrong_. 1998-12-31 23:59:59.047 UTC is
_wrong_. Each one is off by an entire _second_, far more than the error
bound that you claim to achieve.
Don't claim that it's the standard library's fault for screwing this up.
Even in 1998, most systems already used Olson's tz library, which is
perfectly capable of handling leap seconds if you use it in right mode.
The problem is that you insist on using a bogus time scale instead of
the right time scale.
My system, synchronized with clockspeed, produced accurate UTC displays
and local-time displays during that leap second, and will continue to do
so during subsequent leap seconds, just as it does at other times. Your
system didn't, won't, and doesn't. Aren't you embarrassed by this?
---Dan
Petri Kaukasoina
> * I didn't trust xntpd's security. People subsequently discovered
> that xntpd was vulnerable to a remote root exploit. I still don't
> trust xntpd's security.
For Linux users there are patches for (x)ntpd to run as a nonprivileged user
using Linux capabilities.
Nero Imhard
Not an expert, but slightly educated and I've given the matter plenty of
thought...
> Your NTP implementation, however, sets UNIX time in a way that
>
> * throws away information,
> * is not monotonic,
> * produces inaccurate UTC displays,
> * produces inaccurate local-time displays,
Reading this, I get the impression that you are referring to the way
Unix time is implemented; not ntp. These points are precisely what pains
me as well. But don't blame the software that does a good job of
conforming to this madness.
> * is not consistent with the tz library in right mode, and
Uhm... I don't know what you mean by 'right' mode. I could dig up the
docs, but for now I'll assume that it maintains a 'right' count of
seconds, including the leap seconds. Perhaps even UDT or TAI. Right? As
far as I'n concerned that is not compatible with the majority of
implementations. Doesn't this hurt when you need to exchange time
stamps? Think software development, make, NFS, get the picture? Doesn't
the difference accumulate?
Or do you provide a conversion for that purpose? Then in what way is the
result of the conversion better than the time produced by an
ntp-synchronized box?
--Nero
Ulrich Windl
> There are two reasons that I decided to write my own NTP client instead
> of using xntpd:
>
> * I didn't trust xntpd's security. People subsequently discovered
> that xntpd was vulnerable to a remote root exploit. I still don't
> trust xntpd's security.
>
> * I don't like xntpd's bogus interpretation of UNIX time. It doesn't
> give accurate local-time displays. It's also incompatible with the
ntptime, what's wrong with it?
[...]
Vernon Schryver
> ... an interesting addition
>to the NTP protocol machine. This would be provisions to include the
>local time offset from Greenwich in the NTP packet. That's a wonderful
>idea and I thank you for suggesting it.
> ...
I'm sorry, but I think that's a not a good idea today. It would have
made sense and possibly been good in the old BSD days when the offset
from Greenwich was a system wide value kept in the kernel. Today,
every user of a system and every user process for a single user can
have a different offset from Greenwich on all popular UNIX varients.
The System V notion of an TZ environment variable has spread to the
BSD world, and with good reason. It allows a single server in one
timezone to have users in many timezones without making any user have
strange clocks. It is also handy if a user needs to run a program
with different notions of timezone or daylight savings time.
So if you put the offset from Greenwich into the NTP protocol, which
offset would you use?
Vernon Schryver v...@rhyolite.com
Mark Martinec
> Uhm... I don't know what you mean by 'right' mode. I could dig up the
> docs, but for now I'll assume that it maintains a 'right' count of seconds,
> including the leap seconds. Perhaps even UDT or TAI. Right?
I guess he is referring to tzcode/Makefile settings:
# If you always want time values interpreted as "seconds since the epoch
# (not counting leap seconds)", use
# REDO= posix_only
# below. If you always want right time values interpreted as "seconds since
# the epoch" (counting leap seconds)", use
# REDO= right_only
# below. If you want both sets of data available, with leap seconds not
# counted normally, use
# REDO= posix_right
# below. If you want both sets of data available, with leap seconds counted
# normally, use
# REDO= right_posix
# below.
# POSIX mandates that leap seconds not be counted; for compatibility with it,
# use either "posix_only" or "posix_right".
--
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Mark Martinec (system manager) tel +386 1 4773-575 !!
!! J. Stefan Institute, Jamova 39 fax +386 1 2519-385 !!
!! SI-1000 Ljubljana, Slovenia mark.m...@ijs.si !!
!!!!!!!!!!!!!!!!!!!!!!!!!! http://www.ijs.si/people/mark/ !!!!
Nero Imhard
> > including the leap seconds. Perhaps even UDT or TAI. Right?
Let me correct myself. I meant _TDT_ or TAI of course.
> I guess he is referring to tzcode/Makefile settings:
Ah! Thanks for that. So it's "seconds since the epoch". I'll look up how
the posix epoch is defined. But it doesn't really matter for the
argument; it's just another offset.
--N
David L. Mills
See the paper "On the chronology and metrology of computer network
clocks" at www.eecis.udel.edu/~mills/papers.htm. It reveals exactly what
happens at a typical leap. NTP counts seconds; that's all it does. It
does not decode to printable format. I made no such claim the library
screwed anything up; just that the library, not NTP, converts to
printable or any other format. But, I am not surprised that the clock in
your case showed 47 milliseconds fast. From the explanation in my last
message, you can figure it out for yourself.
The first epoch 1998-12-31 23:59:60.047 UTC shows 47 ms into the leap
second itself. Either that is the actual time you read the clock or the
clock was in error 47 ms relative to another source. There is nothing
wrong with it and the library has mapped the printable string correctly.
The library can know a leap (second number 60) is in progress by looking
at the clock status word returned by the kernel, but I bet it does this
by some other scheme.
Precisely one second later than the last reading the time is 1999-01-01
00:00:00.047 UTC, and that is what the library routines should show. The
reason they can do this is because the kernel has in effect repeated the
59th second, but forced the clock to read monotonically. If nothing else
were done, the clock would freeze for that second. However, to satisfy
the Lamport criteria, each reading of the clock must advance, so at
least in my kernel code it advances by at least one nanosecond at each
clock reading.
From an application point of view, the time within the 60th second
appears to gain very slowly until the end of the second, leaving the
clock fast by the amount it gained. Thus the actual error during the
leap second grows to almost one second, then quickly disappears during
the following second. If some dude attempted to read the clock as fast
as it could during the leap second itself, the NTP time would be ahead
of the actual time at the beginning of the second following the leap
second; but, unless the clock can be read faster than one nanosecond per
reading, the error will quickly recede. The fastest machine I have takes
about a microsecond to read the clock. If this is in fact the hazard you
fear, then I plead mea culpa.
A bunch of us here and at national standards labs have carefully
considered the issues pro and con of running computer clocks on TAI,
which has no leap seconds, instead of UTC. I understand this to be the
case in Enterprise/POSIX. The problem is conformance to everyday life,
as considered in the paper/essay cited above, not 32 seconds in the
future, as the case with TAI right now. It is in principle possible to
map TAI to UTC using the NIST leapseconds file obtained either by ftp or
autokey. You would have to install the table in the kernel and use a
state machine to instantiate each new offset as it comes along. In order
to accurately calibrate intervals spanning leap seconds, the library
would have to determine from the table which TAI offset applies at each
historic epoch and of course projections to the future would be
nondeterministic.
You may not like this behavior at all. The Precision Time and Time
Interval meeting is near the end of the year. We would really like to
hear your observations on alternative schemes. I would be glad to pass
your suggestions on to the meeting attendees.
Dave
David L. Mills
How does POSIX get the leap epoches? Both USNO and NIST provide these
data, but not an automated way to get them other than ftp or autokey.
Dave
D. J. Bernstein
> Reading this, I get the impression that you are referring to the way
> Unix time is implemented; not ntp.
UNIX time (time_t, timeval, timespec) is just fine. It counts the number
of seconds since a particular epoch. Programs add and subtract UNIX time
values to accurately measure real-time intervals.
Standard C functions, as implemented by the popular tz library in right
mode, convert UNIX time values to civil time, taking account of all the
complications of civil time---leap seconds, variable DST rules, etc.
The problem is that xntpd/ntpd doesn't set UNIX time properly. It uses a
bogus time scale that jumps backward by 1 at the start (or end? or some
random time after the end?) of every leap second. Consequently we get
incorrect clock displays and incorrect interval measurements. It isn't
even mathematically possible to convert this bogus time scale to UTC.
In contrast, clockspeed sets UNIX time from NTP properly, producing
correct results from all of the aforementioned code.
> Think software development, make, NFS, get the picture?
Synchronize all your machines. End of problem.
---Dan
Wolfgang Rupprecht
"David L. Mills" <mi...@udel.edu> writes:
> How does POSIX get the leap epoches? Both USNO and NIST provide these
> data, but not an automated way to get them other than ftp or autokey.
Some GPS's do give you what is effectively the current TAI-UTC offset.
(Technically it's the "GPS-time" to UTC offset, but GPS time is
essentially TAI with an epoch of jan 1, 1990.
/* convert a garmin gps pvt pkt to unix time */
#define SECONDS_FROM_EPOCH_TO_1990 631065600
gs.gps.fix_time = pvt_pkt->time_of_week
+ (pvt_pkt->offset_days * 60.0 * 60.0 * 24.0)
- pvt_pkt->leap_seconds
+ SECONDS_FROM_EPOCH_TO_1990;
A program could come with a table of past leap seconds and then
accumulate the future leap seconds as they are seen on the wire from
the GPS.
As to would my life be easier if unix time you TAI with a userland
TAI-UTC offset -- YOU BET! While I'm not going to lose any sleep over
the UTC vs TAI thing, it does bother me a small amount that once ever
1.5 years I'm either going to need some contorted code to prevent my
realtime map program from showing infinite speed for the duration of
the leap second.
-wolfgang
--
Wolfgang Rupprecht <wolfga...@dailyplanet.wsrcc.com>
http://www.wsrcc.com/wolfgang/
Coming soon: GPS mapping tools for Open Systems. http://www.gnomad-mapping.com/
Matthias Andree
> However, I should clarify a couple of points you raise. There was in
> fact a security vulnerability, although a really remote one, which had
> existed for over a decade and was recently fixed in NTPv4. As we do not
I'd like to comment on this one. ntpv4 software could start two
dedicated daemons that do special things and drop all privileges
otherwise. It could talk to them through pipes or UNIX domain sockets
(not sure if these are portable to Wind*ze)
One daemon would manage internet connections (adding listeners, binding
to the ntp port is a privileged operation).
One daemon would interface with the kernel for setting time and other
parameters (unless, of course, there's another way, possibly Linux'
CAPABILITES system).
In that case, with some care, the next bug found after over a decade
will not be a root exploit, but an exploit for an unprivileged user.
--
Matthias Andree
Matthias Andree
> > Think software development, make, NFS, get the picture?
>
> Synchronize all your machines. End of problem.
Wow. Do YOU get Solaris synchronized to Linux or BSD? If so, that'd be a
reason. My Solaris boxen are always four seconds off. Might be an
artifact of outdated ntp software, of course.
Matthias Andree
Are those the patches found at
<URL:http://www.uku.fi/~jhuuskon/Patches/> or are there others as well?
--
Matthias Andree
David L. Mills
Golly, you are persuavive. Your agenda is that Unix/NTP time is
defective at its very basis of design and conjecture. You lose.
Dave
Petri Kaukasoina
>kauk...@elektroni.ee.tut.fi (Petri Kaukasoina) writes:
>>
>> For Linux users there are patches for (x)ntpd to run as a nonprivileged user
>> using Linux capabilities.
>
>Are those the patches found at
><URL:http://www.uku.fi/~jhuuskon/Patches/> or are there others as well?
>
That one is against ntp-4.0.99k. The original one for xntp-3:
http://eltopo.engin.umich.edu/caenlinux/6.1/SRPMS/SRPMS/xntp3-5.93-caen_24.src.rpm
Another version of that:
http://www.engin.umich.edu/caen/systems/Linux/code/patches/xntp3-5.93-unpriv.patch
And another one without the need of the libcap library:
http://security-archive.merton.ox.ac.uk/security-audit-200104/0014.html
A related message:
http://security-archive.merton.ox.ac.uk/security-audit-200104/0016.html
Ulrich Windl
> In article <3B9C38D2...@udel.edu>, David L. Mills <mi...@udel.edu> wrote:
>
> > ... an interesting addition
> >to the NTP protocol machine. This would be provisions to include the
> >local time offset from Greenwich in the NTP packet. That's a wonderful
> >idea and I thank you for suggesting it.
> > ...
I thought it was Dave Mills' irony...
Ulrich Windl
> The problem is that xntpd/ntpd doesn't set UNIX time properly. It uses a
Yes, ANSI-C won't allow to set leap indicators, and time_t alone is
not uniquely converted to calendar time without leap
information. ntp_adjtime() is used to set leap information, but it's
not used to set the time (to absolute values). Maybe that's a problem.
> bogus time scale that jumps backward by 1 at the start (or end? or some
> random time after the end?) of every leap second. Consequently we get
> incorrect clock displays and incorrect interval measurements. It isn't
> even mathematically possible to convert this bogus time scale to UTC.
Because you need the leap info.
Matthias Andree
> incorrect clock displays and incorrect interval measurements. It isn't
> even mathematically possible to convert this bogus time scale to UTC.
That's not difficult, it's a matter of causality. Leap-seconds are
non-deterministic. UTC tracks the earth rotation, TAI is independent.
Your clockspeed software is not able to predict the leap seconds before
they're announced, is it?
I have yet to understand what the particular bug about [x]ntpd
is. Pointers to past articles welcome.
--
Matthias Andree
D. J. Bernstein
> I have yet to understand what the particular bug about [x]ntpd is.
The bug is that xntpd/ntpd doesn't use UNIX time properly. The obvious
effects are that people who use xntpd/ntpd to set UNIX time occasionally
see errors of 1 second or more in
* displays of the current time in UTC,
* displays of the current local time,
* displays of past timestamps,
* measurements of real-time intervals, and
* scheduling of real-time events.
In contrast, when I use clockspeed and the tz library in right mode,
none of these errors occur.
> Your clockspeed software is not able to predict the leap seconds before
> they're announced, is it?
The definition of _future_ civil time depends on leap seconds, time
zones, and, if you look a few thousand years ahead, calendar changes.
But that does not excuse inaccurate displays of _present_ and _past_
timestamps. It also does not excuse inaccurate measurement of real-time
intervals.
---Dan
David Woolley
d...@cr.yp.to (D. J. Bernstein) wrote:
> UNIX time (time_t, timeval, timespec) is just fine. It counts the number
> of seconds since a particular epoch. Programs add and subtract UNIX time
> values to accurately measure real-time intervals.
UNIX time has never really worked like this; your problem is that you don't
like the pragmatic way that Unix time works, rather than with NTP.
Initial implementations largely used mains frequency clocks, which are not
precise enough to worry. The time conversion libraries implemented a
model of time in which leap seconds didn't exist and most people reading
the man page are not really aware of leap seconds so would expect it to work
that way (many people who should know better have trouble with timezones
and DST!).
Posix then standardised a lot of Unix and they standardised Unix time as
being strict 86400 hours per day, even if the real day had more or less.
> Standard C functions, as implemented by the popular tz library in right
This function is *non*-standard when used in "right" mode.
I can see an argument for true TAI times, but the vast majority of computer
users and even programmers will have difficulties with that concept.
Many machines cannot be connected to networks for security reasons and
those may often run very old software with old leap second tables; updating
every year is a new phenomenum; people with working, stable, systems will
typically use many year old back versions. Such systems will end up wrong in
both modes. Being part of a self updating global network is the only way
you can make TAI work for most real users.
Incidentally, most bureaucratic organisation want to work in wall clock time
differences, not atomic time differences, and real time delays are typically
implemented in a leap second free time scale; it's only if you then read the
clock and compare that there is a discrepancy.
David L. Mills
I'm losing enthusiasm for this thread.
"D. J. Bernstein" wrote:
>
> Matthias Andree <matthia...@gmx.de> wrote:
> > I have yet to understand what the particular bug about [x]ntpd is.
>
> The bug is that xntpd/ntpd doesn't use UNIX time properly. The obvious
> effects are that people who use xntpd/ntpd to set UNIX time occasionally
> see errors of 1 second or more in
>
> * displays of the current time in UTC,
The NTP daemon cannot do that. If the clock error is over 128 ms, it
will do a step correction or slew adjustment depending on configuration.
> * displays of the current local time,
Tbe NTP daemon does not determine local time. It deals exclusively in
UTC. Local time offsets are the responsibility of the operating system.
This observation has been made repeatedly on this list, but you
apparently were not listening.
> * displays of past timestamps,
The NTP daemon does not display timestamps. It conveys adjustments of
the system clock to agree with local or remote sources of time, as
described in rfc-1305, which you apparently have not read or understood.
> * measurements of real-time intervals, and
The NTP daemon does not measure real-time intervals. Applications do
that.
> * scheduling of real-time events.
The NTP daemon has nothing whatsoever to do with scheduling real-time
events.
>
> In contrast, when I use clockspeed and the tz library in right mode,
> none of these errors occur.
>
> > Your clockspeed software is not able to predict the leap seconds before
> > they're announced, is it?
>
> The definition of _future_ civil time depends on leap seconds, time
> zones, and, if you look a few thousand years ahead, calendar changes.
>
> But that does not excuse inaccurate displays of _present_ and _past_
> timestamps. It also does not excuse inaccurate measurement of real-time
> intervals.
>
> ---Dan
I have no problem whatsoever that clockspeed might indeed be a superior
time wrangler than the NTP daemon, but you have in any way proved your
case. On the contrary, you have shown massive ignorance in what the
daemon and NTP synchronization model is designed to do. You are invited
to produce an engineering model, analysis and design that can be used to
compare and evaluate your methods with others such as NTP, DTSS and PCS
in the literature. If you choose not to do this and do not defend your
model in concrete terms with relevance to these protocols and the model
they represent, I do not personally wish to continue this exchange and
will resist the urge to comment on further messages. In the politest and
kindest terms I can offer, please shut up.
Dave
D. J. Bernstein
> I can see an argument for true TAI times, but the vast majority of computer
> users and even programmers will have difficulties with that concept.
Users want accurate local-time clocks. They don't give a damn about the
internal numbers that UNIX uses for time values.
Programmers add and subtract UNIX time values to handle real-time
intervals. This is a massive amount of code. It's not going away. It
all works just fine if you set the time properly.
> The time conversion libraries implemented a
> model of time in which leap seconds didn't exist
Your information is out of date. That bug was fixed years ago in Olson's
popular tz library. (By the way, when the original UNIX time conversion
libraries were written, leap seconds _didn't_ exist.)
> Posix then standardised a lot of Unix and they standardised Unix time as
> being strict 86400 hours per day, even if the real day had more or less.
Your information is out of date. The relevant POSIX committee has agreed
to fix this.
---Dan
D. J. Bernstein
> The NTP daemon cannot do that.
False. For example, many xntpd/ntpd users were watching their UNIX
clocks closely through the 1998-12-31 23:59:60 UTC leap second, and
observed 1-second errors in the UTC and local-time displays---because
you insist on using UNIX in an obsolete mode that never displays 60.
You keep saying that these failures aren't your fault. You keep saying
that other programs are responsible for clock displays and interval
measurements. How do you expect those programs to do their jobs, when
you are _throwing away crucial information_ in the time values that you
supply to them?
You talk about a pie-in-the-sky solution: rewrite every time-handling
program to extract this missing information from some kernel interface
you've invented. Why don't you stick to the _existing_ interface that
the programs _already_ use? That's what I do. Everything works.
The bottom line, as I said, is that you're not using UNIX time properly.
---Dan
Joe Gwinn
Bernstein) wrote:
> David Woolley <da...@djwhome.demon.co.uk> wrote:
[snip]
>
> > Posix then standardised a lot of Unix and they standardised Unix time as
> > being strict 86400 hours per day, even if the real day had more or less.
>
> Your information is out of date. The relevant POSIX committee has agreed
> to fix this.
Unfortunately, no. We tried, but a holy war resulted, and so the
committee just clarified the original wording from 1988, now stating that
a day in POSIX contains exactly 86,400 seconds, and that leap seconds are
not applied. Before, this was implied, but not clearly stated, leading to
some violent disputes about the meaning and intent of the 1988 words.
I provided the relevant text of the new POSIX standard (P1003.3-200x) in
"Time-related extract of the POSIX standard to come" posted to
<comp.protocols.time.ntp> on 6 July 2001.
The opportunity to fix the problems with leap seconds was thus lost,
because the time folk became mired in a violent feud, causing the POSIX
committee to run for cover. Time simply isn't that important to them.
The next opportunity to fix the standard will be something like five years
from now. By that time, perhaps a solution will have been found. If not,
nothing will change, and the problem will simply remain unsolved, and life
will go on.
My personal preference would be to base POSIX Scalar Time (aka, Seconds
Since the Epoch) explicitly on TAI, providing slowly-growing leapsecond
tables to allow translation to and from UTC as needed. In this approach,
NTP would also be TAI-based, or at a constant offset from TAI (like GPS
System Time). Given that TAI is the most fundamental of the standard
clocks, which are defined in terms of perhaps indirect deltas from TAI,
using TAI seems like the cleanest and most direct approach to me. Given
that POSIX Scalar Time already behaves much like TAI, thereby sharply
reducing the software disruption that changing to TAI would entail, it
might be possible to sell such a proposal, but only if the feuds have been
settled well before.
Joe Gwinn
D. J. Bernstein
and that localtime() convert time_t to local time. An implementation of
gmtime() that can't return 1998-12-31 23:59:60 is obviously deficient.
The question here is whether POSIX requires deficient implementations.
Joe Gwinn <joeg...@mediaone.net> wrote:
> now stating that a day in POSIX contains exactly 86,400 seconds
The rationale then correctly concludes that this is ``not necessarily
UTC, despite its appearance,'' because UTC includes leap seconds. So it
also isn't necessarily the return value of gmtime().
---Dan
David L. Mills
Yes, the timefolk did "discuss" the issue, but came to no nonviolent
conclusion. The problem runs much deeper than that and I won't bore the
list with details, but hints are that radio timecode formats would have
to change, your TV set might have to download leapsecond tables and
similar trivia. What tipped the bucket was a hint of fear that, given
the offset slope is decreasing with age - that we might have to
<<delete>> a second some time in the future. The NIST stations, at
least, can't handle that. What happens if the GPS offset goes
<<negative>>?
We did discuss switching from UTC to TAI time in the computers of the
world. I was amazed at how many institutions are running UTC time with
NTP, like broadcast radio and TV networks, stock exchanges, aircraft
traffic control, etc., that would have to make massive changes in
installed software. If you can observe POSIX feud,s you should see the
timekeeper feuds.
Dave
Matthias Andree
> You keep saying that these failures aren't your fault. You keep saying
> that other programs are responsible for clock displays and interval
> measurements. How do you expect those programs to do their jobs, when
> you are _throwing away crucial information_ in the time values that you
> supply to them?
Time value*s* (plural)? The time() interface returns a single time_t
value, be that long, long long or whatever else of >= 32 bit precision.
What is the precise manifestation of the problem? What is the test
scheme I can run the next time a leap second is scheduled?
> You talk about a pie-in-the-sky solution: rewrite every time-handling
> program to extract this missing information from some kernel interface
> you've invented. Why don't you stick to the _existing_ interface that
> the programs _already_ use? That's what I do. Everything works.
What existing interface in particular do you use? Which system and
library functions? That might help the discussion a lot.
--
Matthias Andree
"Those who give up essential liberties for temporary safety deserve
neither liberty nor safety." - Benjamin Franklin
Joe Gwinn
Bernstein) wrote:
> The ANSI C specification requires that gmtime() convert time_t to UTC,
> and that localtime() convert time_t to local time. An implementation of
> gmtime() that can't return 1998-12-31 23:59:60 is obviously deficient.
> The question here is whether POSIX requires deficient implementations.
I have to wonder how any language can require UTC, which cannot be
implemented without access to leapsecond tables? No algorithm can tell
one when the leap seconds will be; these can be known only from
astronomical observation.
This is the reason that POSIX does not claim to implement UTC. No
isolated system can know UTC. So, it's ANSI C that's deficient, in that
it required the impossible.
That said, what gmtime does is to convert between Seconds Since the Epoch
(POSIX Scalar Time) and POSIX Broken-Down Time, which resembles UTC but
lacks the leap seconds.
> Joe Gwinn <joeg...@mediaone.net> wrote:
> > now stating that a day in POSIX contains exactly 86,400 seconds
>
> The rationale then correctly concludes that this is ``not necessarily
> UTC, despite its appearance,'' because UTC includes leap seconds. So it
> also isn't necessarily the return value of gmtime().
Yes.
Joe Gwinn
Joe Gwinn
In article <3BA41836...@udel.edu>, "David L. Mills" <mi...@udel.edu>
wrote:
> Joe,
>
> Yes, the timefolk did "discuss" the issue, but came to no nonviolent
> conclusion. The problem runs much deeper than that and I won't bore the
> list with details, but hints are that radio timecode formats would have
> to change, your TV set might have to download leapsecond tables and
> similar trivia.
I guess I don't really see what these all have to do with how POSIX keeps
time internally.
What tipped the bucket was a hint of fear that, given
> the offset slope is decreasing with age - that we might have to
> <<delete>> a second some time in the future. The NIST stations, at
> least, can't handle that. What happens if the GPS offset goes
> <<negative>>?
I don't think I'll live to see the total UTC-GPS offset, currently 13
seconds, go negative, even if we have some negative leap seconds. The GPS
signal in space does support negative leap seconds.
But if the total count does become negative, lots will need to be fixed,
and it will be the golden opportunity to fix many things that we have
heretofor just lived with.
> We did discuss switching from UTC to TAI time in the computers of the
> world. I was amazed at how many institutions are running UTC time with
> NTP, like broadcast radio and TV networks, stock exchanges, aircraft
> traffic control, etc., that would have to make massive changes in
> installed software.
The "we" above would be the NTP community, I assume. I would guess that
those time users want UTC from their computer clocks, but never heard of
TAI, and don't really care what kind of time NTP uses internally.
The ATC folk of my experience do run NTP slaved to GPS, and just ignore
leap second issues in messages between systems. However, the people
implementing the trackers most often avoid leap-second issues by using
some kind of non-UTC unambiguous and uniform timescale for the
calculations.
In the radar systems I am involved with, we often slave NTP to GPS System
Time (expressed in a UTC-like format), not UTC from the same GPS receiver,
largely because we cannot tolerate time discontinuities. Like a "second"
that lasts two SI seconds. These are the same reasons the ATC tracker
folk avoid leap seconds
> If you can observe POSIX feuds, you should see the
> timekeeper feuds.
I've seen a bit of both now.
Summary. I guess I'm not trying to solve world hunger, only to straighten
out things in POSIX timekeeping, and it seems to me that defining the
POSIX Epoch directly in terms of TAI would solve a number of problems. It
also seems to me that Olson's tz library already defines the Epoch in
terms of TAI, but picks out an instant that differs from the current POSIX
Epoch by about two seconds.
NTP, with its existing base, is a whole different ball of wax.
Joe
David L. Mills
I don't care what POSIX does internally. I do care that the computer
that starts the VCR in the control room for the news at six intro knows
the right UTC second.
You might not have noticed it, but I have seen several news programs
with clocks in view, plus the clock the local cable company uses to
switch the converter channel on command are astonishly accurate. With a
radio timecode display held next to the screen, I estimate no more than
50 ms error, which is the smallest I can judge by eyeball. This exotic
observation is not intended to argue for anything other than suggest
there are a lot of NTP gizmos lurking all over the place. Yes, I do know
PBS uses NTP for member station synchronization.
Dave
David L. Mills
I don't care what POSIX does internally. I do care that the computer
that starts the VCR in the control room for the news at six intro knows
the right UTC second.
You might not have noticed it, but I have seen several news programs
with clocks in view, plus the clock the local cable company uses to
switch the converter channel on command are astonishly accurate. With a
radio timecode display held next to the screen, I estimate no more than
50 ms error, which is the smallest I can judge by eyeball. This exotic
observation is not intended to argue for anything other than suggest
there are a lot of NTP gizmos lurking all over the place. Yes, I do know
PBS uses NTP for member station synchronization.
Dave
D. J. Bernstein
> I have to wonder how any language can require UTC, which cannot be
> implemented without access to leapsecond tables?
``I wonder how any language can require local time? It's impossible to
do a high-quality localtime() implementation without leap-second tables
_and_ a constantly expanding database of time-zone information.''
Yes, civil time is complicated. But that doesn't excuse screwing it up!
These databases are easier to distribute than accurate timestamps.
By the way, ANSI C allows embedded (``freestanding'') implementations
that omit various parts of the standard library. However, any parts of
the library that are included must be implemented correctly. Users are
justified in complaining when gmtime() and localtime() and difftime()
produce inaccurate results.
---Dan
D. J. Bernstein
> Time value*s* (plural)?
The current time keeps changing, see? When you call gettimeofday() now,
and then call it again a while later, you get two different values.
With the bogus xntpd/ntpd time scale, these values are missing crucial
information, and cannot be converted accurately to UTC or to local time.
In contrast, with the right time scale and the tz library, these values
are converted accurately to UTC and to local time.
> What is the precise manifestation of the problem?
There are all these programs on your system that deal with times, see?
Watch them carefully through a leap second on an xntpd/ntpd system, and
you will observe inaccurate results.
For example: ``date -u'' is supposed to tell you the current date and
time in your local time zone. On typical xntpd/ntpd systems, when the
actual time was 1998-12-31 23:59:60 UTC, ``date -u'' displayed a result
that was off by one second. Same for every other program that used the
standard time functions.
Of course, this example has only one-second precision anyway, but the
same one-second error appears in microsecond and nanosecond timestamps.
There is a massive amount of code of the form
gettimeofday(&tv0,0);
doit();
gettimeofday(&tv1,0);
printf("doit took %.0f microseconds.\n"
,(tv1.tv_sec - tv0.tv_sec) * 1000000.0 + (tv1.tv_usec - tv0.tv_usec));
which, with the bogus xntpd/ntpd time scale, produces wildly inaccurate
results around leap seconds.
In contrast, when I use clockspeed to synchronize my clock with NTP, and
I enable right mode in the tz library, these problems disappear. I get
accurate local-time displays and accurate interval measurements.
---Dan
Matthias Andree
> Matthias Andree <matthia...@gmx.de> wrote:
> > Time value*s* (plural)?
>
> The current time keeps changing, see? When you call gettimeofday() now,
> and then call it again a while later, you get two different values.
Now, that's finally the name of one of the interfaces you referred
to. It's a BSD-derived one.
> > What is the precise manifestation of the problem?
>
> There are all these programs on your system that deal with times, see?
> Watch them carefully through a leap second on an xntpd/ntpd system, and
> you will observe inaccurate results.
>
> For example: ``date -u'' is supposed to tell you the current date and
> time in your local time zone. On typical xntpd/ntpd systems, when the
^
... Universal Time
POSIX has no notion of 23:59:60. POSIX-compliant tools will fail. Seems
like NTP has chosen to be POSIX compliant.
> In contrast, when I use clockspeed to synchronize my clock with NTP, and
> I enable right mode in the tz library, these problems disappear. I get
> accurate local-time displays and accurate interval measurements.
"right mode" makes a difference, doesn't it? POSIX has no notion of leap
seconds when it comes to its time stamp.
However, switching [x]ntpd to use the "right" time scale rather than the
POSIX time scale may fix this problem, but it gives rise to a new one: A
Unix time stamp does not contain information if it's a "right" or a
"posix" (deliberately broken) time stamp. So effectively, all time
stamps you encounter may be up to 22 seconds off, until the next leap
seconds -- then up to 23 s off.
#include <time.h>
#include <stdio.h>
main() {
struct tm t[] =
{ { 59,59,23,31,11,98,0,0,0 },
{ 60,59,23,31,11,98,0,0,0 },
{ 0,0,0,1,0,99,0,0,0 }};
int m = sizeof(t)/sizeof(t[0]);
int i;
for (i = 0; i < m; i++) {
printf("%ld\n", mktime(&t[i]));
}
}
> TZ=UTC ./trytz # same with posix/UTC
915148799
915148800
915148800
> TZ=right/UTC ./trytz
915148820
915148821
915148822
It's not just ntp, it's everything that's POSIX compliant when it comes
to time stamps that is broken like this.
It's taken me quite some time to figure that you want ntp to use the
"right" scale as per Olson's library to prevent breaking the monotony at
leap seconds.
http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-algo.htm#AEN2058
http://cr.yp.to/proto/utctai.html regretfully does not show the
interface you used to obtain the right-hand column in your
1997-06-30 23:59:60.9 UTC -> 867715200.9 xntpd
1997-07-01 00:00:00.0 UTC -> 867715200.0 xntpd
listing. Was it time()? gettimeofday()?
To the NTP team, it might be useful to add a switch (e. g. --right) to
use Olson's "right" time zone on systems that support it.
Mike
wrote:
[snip]
> Yes, I do know
> PBS uses NTP for member station synchronization.
Hmmmm... my VCR "synchronizes" to the time signal that is broadcast on
the PBS television signal. Yet my VCR consistently runs about 15
seconds behind the ntp clock on my computers.
I wonder if my VCR has an incorrect implementation of its time sync
software (whatever it may use)?
David L. Mills
That's not the signal that synchronizes the VCRs. I have noticed the
local PBS station really has gotten their act together and starts the
program on the right second. This is a relatively new development.
Dave
David L. Mills
That's not the signal that synchronizes the VCRs. I have noticed the
local PBS station really has gotten their act together and starts the
program on the right second. This is a relatively new development.
Dave
David L. Mills
That's not the signal that synchronizes the VCRs. I have noticed the
local PBS station really has gotten their act together and starts the
program on the right second. This is a relatively new development.
Dave
Mike
the correct time sync, since there are a few million or so VCRs
sync'ing to them.
But I am not as much concerned about WNET starting their shows
precisely on the hour, I am more concerned that I always miss the
first 15 seconds of the TV shops I record. :-(
Maybe I should send them an email and ask 'em what's up. Lately, I've
just disabled the automatic time sync in the VCR. Now all I have to
deal with is clock drift.
On Mon, 17 Sep 2001 16:03:53 +0100, "David L. Mills" <mi...@udel.edu>
Clifton T. Sharp Jr.
> Hmmmm... my VCR "synchronizes" to the time signal that is broadcast on
> the PBS television signal. Yet my VCR consistently runs about 15
> seconds behind the ntp clock on my computers.
>
> I wonder if my VCR has an incorrect implementation of its time sync
> software (whatever it may use)?
Just FYI, that's done through the XDS (eXtended Data Service) transmitted
in the vertical blanking interval. They transmit both a "current time" (and
date) record (in UTC) and a "timezone" record containing a DST flag. A
"zero" bit in the "current time" record is sent on the minute at xx:yy:00,
and that's when the clock is set, naturally.
15 seconds is a bit much for it to be off. It could actually be that the
station has their clock (on the XDS generator gizmo) set wrong. One station
local to me was transmitting some really bogus times when they first
started sending the data; turned out they weren't replacing the data
contained in the downlink, so shows were setting the VCR time to whatever
time the show was downlinked instead of real time.
I have no data on when precisely the "zero" flag is valid, but there are
six bytes in the "current time" record (plus the two which identify the
record type), and data comes at two bytes per frame (not field, frame),
so in the absence of good data I call the ambiguity at about 67 milliseconds.
Not enough to explain fifteen seconds.
Some of the premium services (HBO etc.) ignore the spec and send their
local time in the "current time" data, with no "timezone" record. Luckily
they never set the "zero" bit in the "current time" record.
--
"I would have been happy to explain further, except you had by that
point made it clear you would believe whatever you wanted to believe"
-- Jamie McCarthy, <b613732a.01070...@posting.google.com>
David L. Mills
Sync your VCR from the computer. And, please do tweak them on the
eyebrow code time.
Dave
David L. Mills
Sync your VCR from the computer. And, please do tweak them on the
eyebrow code time.
Dave
Ian Molton
"Clifton T. Sharp Jr." <cli...@clifto.com> (might have) scribbled
insanely:
> Mike wrote:
> > Hmmmm... my VCR "synchronizes" to the time signal that is broadcast on
> > the PBS television signal. Yet my VCR consistently runs about 15
> > seconds behind the ntp clock on my computers.
> >
> > I wonder if my VCR has an incorrect implementation of its time sync
> > software (whatever it may use)?
>
> Just FYI, that's done through the XDS (eXtended Data Service)
transmitted
> in the vertical blanking interval. They transmit both a "current time"
(and
> date) record (in UTC) and a "timezone" record containing a DST flag. A
> "zero" bit in the "current time" record is sent on the minute at
xx:yy:00,
> and that's when the clock is set, naturally.
Funky idea...
can TV cards read this data?
if so, do you think I could write a utility to get the info from my TVcard
and sync my clock to it? (perhaps an ntp driver?)
Mike
week, I have another data point. The PBS station I had been sync'ing
to, WNET, had its antenna on the World Trade Tower. Obviously, they
are no longer broadcasting. My cable system has substituted a PBS
station from BridgePort, CT on that channel.
Now my VCR sync's up to be 30 seconds slow. :-( So it is back to
manual synchronization with my PC or WWV on shortwave.
With your detailed technical info, I'll be able to write them a
reasonably coherent note, asking them to correct the time they
transmit.
Thanks again.
Clifton T. Sharp Jr.
> Now my VCR sync's up to be 30 seconds slow. :-( So it is back to
> manual synchronization with my PC or WWV on shortwave.
>
> With your detailed technical info, I'll be able to write them a
> reasonably coherent note, asking them to correct the time they
> transmit.
As far as I can tell, stations are running the XDS on PC's. In your note,
tell them about the many NTP implementations available for Windoze. :)
Mike
<cli...@clifto.com> wrote:
>Mike wrote:
>> Now my VCR sync's up to be 30 seconds slow. :-( So it is back to
>> manual synchronization with my PC or WWV on shortwave.
>>
>> With your detailed technical info, I'll be able to write them a
>> reasonably coherent note, asking them to correct the time they
>> transmit.
>
>As far as I can tell, stations are running the XDS on PC's. In your note,
>tell them about the many NTP implementations available for Windoze. :)
>
Thanks. Will do.
Paul Keinanen
wrote:
>Golly, you are persuavive. Your agenda is that Unix/NTP time is
>defective at its very basis of design and conjecture. You lose.
While this discussion seems to concentrate on the fact that for some
applications the local time is the correct solution, for other
problems UTC is the correct one and for some problems TAI/IAT (or GPS)
is the best solution, I wonder if anybody have any suggestions how to
handle the following situation.
In a real time control system requiring uniform time for closed loop
control (but in which the local or UTC time is not of very great
importance, since it is used only for human interface and an accuracy
of 1 minute is sufficient), I wonder how to implement a linear time.
RFC 1305 states that the Leap Indicator in the NTP header is set one
"day" (I assume 86400 seconds) prior to the actual insertion (or
removal) of one second. This works fine, since when detecting the LI
bits an internal flag is set and when the LI bits disappear, one
second should be added (or subtracted) to get a linear time scale.
However, if the internet connection is broken for more than 24 hours
just before insertion (or removal) of a leap second, this information
is lost. When the connection is re-established, the internal clock
will be off by 1 s compared to the NTP time. In order to avoid
catastrophic failures, this error is eliminated during the next 100 to
10000 seconds.
Any ideas how to avoid this unnecessary time slewing in case of
internet connection failure for more than 24 h ?
I really hope that the next version of NTP message format will include
a field (as in GPS) that contains the difference between TAI and UTC.
Paul
D. J. Bernstein
> Any ideas how to avoid this unnecessary time slewing in case of
> internet connection failure for more than 24 h ?
clockspeed uses a separate table of leap seconds. New leap seconds, like
new time zones, are announced several months in advance.
The only reason clockspeed looks at the NTP leap-second bit is to
distinguish the NTP encoding of 23:59:60 from the NTP encoding of
00:00:00. I'm considering changing it to simply refuse to talk to NTP
servers near leap seconds; I've never seen an NTP server handle a leap
second correctly, even though it's theoretically possible.
---Dan
David L. Mills
As you know, NTPv4 currently disseminates leapsecond values for the
current and historic epoches of insertion. This is done using the NIST
table and Autokey protocol. You must have my kernel modifications, which
are in current Alpha, Solaris, FreeBSD and Linux. The current TAI offset
is returned in the ntp_gettime() call in FreeBSD and Linux. Thanks for
tickling me - the code to set the kernel leap bits when the leap epoch
is within the day is yet to be built. I promise to do those couple of
lines before the next leap.
The next version of NTP for the Interplanetary Internet will use
solar-system Barymetric Dynamic Time (TDB), not this UTC kidstuff. You
can compute TDB from Terrestrial Dynamic Time (TDT) from TAI,
ephemerides of the planetary orbits and masses of the Sun and planets,
corrected for relativistic effects. Mean solar time will be discontinued
along with leap seconds necessary to align UTC with TAI. The leapsecond
table will be replaced by suitable ephemerides tables necessary to
calculate TDB. Floating double hardware and knowledge of celestial
mechanics will will be required to perform these calculations. Julian
day numbers and fractions will be used instead of clumsy calendar dates
and conventional clock times. You think I'm kidding? See the web
www.eecis.udel.edu/~mills/ipin.htm. Just getting started...
Dave
David L. Mills
As you know, NTPv4 currently disseminates leapsecond values for the
current and historic epoches of insertion. This is done using the NIST
table and Autokey protocol. You must have my kernel modifications, which
are in current Alpha, Solaris, FreeBSD and Linux. The current TAI offset
is returned in the ntp_gettime() call in FreeBSD and Linux. Thanks for
tickling me - the code to set the kernel leap bits when the leap epoch
is within the day is yet to be built. I promise to do those couple of
lines before the next leap.
The next version of NTP for the Interplanetary Internet will use
solar-system Barymetric Dynamic Time (TDB), not this UTC kidstuff. You
can compute TDB from Terrestrial Dynamic Time (TDT) from TAI,
ephemerides of the planetary orbits and masses of the Sun and planets,
corrected for relativistic effects. Mean solar time will be discontinued
along with leap seconds necessary to align UTC with TAI. The leapsecond
table will be replaced by suitable ephemerides tables necessary to
calculate TDB. Floating double hardware and knowledge of celestial
mechanics will will be required to perform these calculations. Julian
day numbers and fractions will be used instead of clumsy calendar dates
and conventional clock times. You think I'm kidding? See the web
www.eecis.udel.edu/~mills/ipin.htm. Just getting started...
Dave
David L. Mills
I have personally watched at least a portion of the Internet on every
leapsecond epoch since 1981. When the radio gives warning, when the
kernel is equipped and the radio is properly synchronized, the leap
really does work. Last verified with the WWV/H audio driver and out
NTPv4 herd here in January 1999. I don't think your clockspeed should
use NTP at all; better to maintain parallel cultures and compare notes
and war stories from time to time.
Dave
Paul Keinanen
>clockspeed uses a separate table of leap seconds. New leap seconds, like
>new time zones, are announced several months in advance.
Unfortunately not very practical to manually distribute this table to
dozens (or perhaps a few hundred sites) all across the globe.
Paul
Paul Keinanen
wrote:
>As you know, NTPv4 currently disseminates leapsecond values for the
>current and historic epoches of insertion. This is done using the NIST
>table and Autokey protocol.
Thanks for the reply. I know about getting the table by ftp from
various places, but requiring manual interventions will degrade the
total system reliability.
> You must have my kernel modifications, which
>are in current Alpha, Solaris, FreeBSD and Linux. The current TAI offset
>is returned in the ntp_gettime() call in FreeBSD and Linux.
In the system that I am thinking about, there is a master clock
running on a site, which may be connected to some external timing
source (NTP, GPS etc.) or might be free running, can be some
non-unix/linux system or even some embedded processor without a
floating point processor.
Thus, I have to implement my own version similar to SNTP and trying to
determine the PLL characteristics for the main clock source and as
well as for other local nodes on the same LAN following the main
clock.
> Thanks for
>tickling me - the code to set the kernel leap bits when the leap epoch
>is within the day is yet to be built. I promise to do those couple of
>lines before the next leap.
Do I understand correctly, that the current NTP servers do not handle
the LI bits as described in RFC-1305 and RFC-2030 ? If this really is
the case, I hope that the addition is made as soon as possible, since
it may take some time, until all servers are updated with the new code
version, hopefully updated before the next leap second.
I only browsed through some of the 4.1.71 code in a very superficial
way, but did not find how this was handled.
Anyway, in my case I guess that I don't even try to run the system in
TAI (due to the complexity of distributing the TAI/UTC tables) or
bother with the LeapIndicator, if not all servers handle it properly.
In my case it is simpler to assume that there can be a +/-1 s jump in
the NTP time and run the clocks 100 ppm high or low for a few hours to
catch up or simply accept that there is an integer number of seconds
difference in the times and corrective this during the next preventive
maintenance the next year or some years from now. The absolute
accuracy is not very important, it is much more important that all
systems on the site have the same time and that the time is linear, so
that the time _intervals_ are correct.
>The next version of NTP for the Interplanetary Internet will use
>solar-system Barymetric Dynamic Time (TDB), not this UTC kidstuff. You
>can compute TDB from Terrestrial Dynamic Time (TDT) from TAI,
>ephemerides of the planetary orbits and masses of the Sun and planets,
>corrected for relativistic effects. Mean solar time will be discontinued
>along with leap seconds necessary to align UTC with TAI. The leapsecond
>table will be replaced by suitable ephemerides tables necessary to
>calculate TDB.
These parameters should be transmitted in the timing message as is
done with the GPS navigational messages (or in the lower precision
values in the GPS almanac). Without a synchronous parameter
distribution mechanism, maintaining such a system becomes a nightmare.
Paul
Matthias Andree
> >clockspeed uses a separate table of leap seconds. New leap seconds, like
> >new time zones, are announced several months in advance.
>
> Unfortunately not very practical to manually distribute this table to
> dozens (or perhaps a few hundred sites) all across the globe.
The file can be offered through rsync and ftp in parallel, and
downloaded once every month, that should be pretty sufficient given that
leap seconds are known approx. half a year in advance. Or am I missing
something here?
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
Matthias Andree
> >clockspeed uses a separate table of leap seconds. New leap seconds, like
> >new time zones, are announced several months in advance.
>
> Unfortunately not very practical to manually distribute this table to
> dozens (or perhaps a few hundred sites) all across the globe.
The file can be offered through rsync and ftp in parallel, and
downloaded once every month, that should be pretty sufficient given that
leap seconds are known approx. half a year in advance.
Of course, it's more useful to have the protocol carry that information,
and "leap second information lacks if the connection is broken" issue is
serious, so one might better transmit a timestamp "next/last leap second
on DATE" rather than just a "leap second at the end of this
day". Systems probably won't be so badly broken that they miss two leap
seconds in a row, I believe. Or am I missing something here?
David L. Mills
Paul Keinanen wrote:
>
> On Sat, 27 Oct 2001 22:25:33 +0100, "David L. Mills" <mi...@udel.edu>
> wrote:
>
> >As you know, NTPv4 currently disseminates leapsecond values for the
> >current and historic epoches of insertion. This is done using the NIST
> >table and Autokey protocol.
>
> Thanks for the reply. I know about getting the table by ftp from
> various places, but requiring manual interventions will degrade the
> total system reliability.
The Autokey protocol retrieves the table automatically and verifies
using public key cryptography. While the current NTPv4 supports this, I
suspect the NIST servers themselves are not running the latest version.
> > You must have my kernel modifications, which
> >are in current Alpha, Solaris, FreeBSD and Linux. The current TAI offset
> >is returned in the ntp_gettime() call in FreeBSD and Linux.
>
> In the system that I am thinking about, there is a master clock
> running on a site, which may be connected to some external timing
> source (NTP, GPS etc.) or might be free running, can be some
> non-unix/linux system or even some embedded processor without a
> floating point processor.
>
> Thus, I have to implement my own version similar to SNTP and trying to
> determine the PLL characteristics for the main clock source and as
> well as for other local nodes on the same LAN following the main
> clock.
If the master clock implements one of the kernels I mentioned and uses a
reference source that provides LI functions, such as most of the GPS,
WWV, WWVB and DCF drivers in the current version, the master clock will
reveal LI status and implement the leap exactly as it occurs. As for PLL
engineeing, see the papers and reports at www.eecis.udel.edu/~mills. In
particular, see: Mills, D.L. Modelling and analysis of computer network
clocks. Electrical Engineering Department Report 92-5-2, University of
Delaware, May 1992, 29 pp and papers since then on design refinements.
More hints via the NTP project page at www.ntp.org.
> > Thanks for
> >tickling me - the code to set the kernel leap bits when the leap epoch
> >is within the day is yet to be built. I promise to do those couple of
> >lines before the next leap.
>
> Do I understand correctly, that the current NTP servers do not handle
> the LI bits as described in RFC-1305 and RFC-2030 ? If this really is
> the case, I hope that the addition is made as soon as possible, since
> it may take some time, until all servers are updated with the new code
> version, hopefully updated before the next leap second.
Both NTPv3 and NTPv4 implementations do in fact implement the leap as
described, although tne NTPv3 scheme was seriously awkward and didn't
work correctly in practice. However, in either version and without
kernel support the leap in general is not inserted at the same time. My
comment had strictly to deal with the NIST leap table; the drivers and
other protocol machinery are just fine. My code would have to sniff the
leap table downloaded from the server and set the system leap bit on the
day of the leap. As I said, a couple of lines of C at the right spot.
> I only browsed through some of the 4.1.71 code in a very superficial
> way, but did not find how this was handled.
>
> Anyway, in my case I guess that I don't even try to run the system in
> TAI (due to the complexity of distributing the TAI/UTC tables) or
> bother with the LeapIndicator, if not all servers handle it properly.
> In my case it is simpler to assume that there can be a +/-1 s jump in
> the NTP time and run the clocks 100 ppm high or low for a few hours to
> catch up or simply accept that there is an integer number of seconds
> difference in the times and corrective this during the next preventive
> maintenance the next year or some years from now. The absolute
> accuracy is not very important, it is much more important that all
> systems on the site have the same time and that the time is linear, so
> that the time _intervals_ are correct.
If you tell ntpd to use only slew mode, it will behave as you describe.
However, the problem is that, for expected accuracy better than some
fraction of a second, while the various machines are slewing, and until
they reach the step limit, applications must consider the network
unsynchronized.
>
> >The next version of NTP for the Interplanetary Internet will use
> >solar-system Barymetric Dynamic Time (TDB), not this UTC kidstuff. You
> >can compute TDB from Terrestrial Dynamic Time (TDT) from TAI,
> >ephemerides of the planetary orbits and masses of the Sun and planets,
> >corrected for relativistic effects. Mean solar time will be discontinued
> >along with leap seconds necessary to align UTC with TAI. The leapsecond
> >table will be replaced by suitable ephemerides tables necessary to
> >calculate TDB.
>
> These parameters should be transmitted in the timing message as is
> done with the GPS navigational messages (or in the lower precision
> values in the GPS almanac). Without a synchronous parameter
> distribution mechanism, maintaining such a system becomes a nightmare.
Yes, GPS is the intended model, but the delays are huge and connectivity
not always available and the NASA Deep Space Net is ponderously slow.
Can't be synchronous, but TDB is at least computable if you have the
necessary interdependent ephemerides.
Dave
>
> Paul
David L. Mills
Paul Keinanen wrote:
>
> On Sat, 27 Oct 2001 22:25:33 +0100, "David L. Mills" <mi...@udel.edu>
> wrote:
>
> >As you know, NTPv4 currently disseminates leapsecond values for the
> >current and historic epoches of insertion. This is done using the NIST
> >table and Autokey protocol.
>
> Thanks for the reply. I know about getting the table by ftp from
> various places, but requiring manual interventions will degrade the
> total system reliability.
The Autokey protocol retrieves the table automatically and verifies
using public key cryptography. While the current NTPv4 supports this, I
suspect the NIST servers themselves are not running the latest version.
> > You must have my kernel modifications, which
> >are in current Alpha, Solaris, FreeBSD and Linux. The current TAI offset
> >is returned in the ntp_gettime() call in FreeBSD and Linux.
>
> In the system that I am thinking about, there is a master clock
> running on a site, which may be connected to some external timing
> source (NTP, GPS etc.) or might be free running, can be some
> non-unix/linux system or even some embedded processor without a
> floating point processor.
>
> Thus, I have to implement my own version similar to SNTP and trying to
> determine the PLL characteristics for the main clock source and as
> well as for other local nodes on the same LAN following the main
> clock.
If the master clock implements one of the kernels I mentioned and uses a
reference source that provides LI functions, such as most of the GPS,
WWV, WWVB and DCF drivers in the current version, the master clock will
reveal LI status and implement the leap exactly as it occurs. As for PLL
engineeing, see the papers and reports at www.eecis.udel.edu/~mills. In
particular, see: Mills, D.L. Modelling and analysis of computer network
clocks. Electrical Engineering Department Report 92-5-2, University of
Delaware, May 1992, 29 pp and papers since then on design refinements.
More hints via the NTP project page at www.ntp.org.
> > Thanks for
> >tickling me - the code to set the kernel leap bits when the leap epoch
> >is within the day is yet to be built. I promise to do those couple of
> >lines before the next leap.
>
> Do I understand correctly, that the current NTP servers do not handle
> the LI bits as described in RFC-1305 and RFC-2030 ? If this really is
> the case, I hope that the addition is made as soon as possible, since
> it may take some time, until all servers are updated with the new code
> version, hopefully updated before the next leap second.
Both NTPv3 and NTPv4 implementations do in fact implement the leap as
described, although tne NTPv3 scheme was seriously awkward and didn't
work correctly in practice. However, in either version and without
kernel support the leap in general is not inserted at the same time. My
comment had strictly to deal with the NIST leap table; the drivers and
other protocol machinery are just fine. My code would have to sniff the
leap table downloaded from the server and set the system leap bit on the
day of the leap. As I said, a couple of lines of C at the right spot.
> I only browsed through some of the 4.1.71 code in a very superficial
> way, but did not find how this was handled.
>
> Anyway, in my case I guess that I don't even try to run the system in
> TAI (due to the complexity of distributing the TAI/UTC tables) or
> bother with the LeapIndicator, if not all servers handle it properly.
> In my case it is simpler to assume that there can be a +/-1 s jump in
> the NTP time and run the clocks 100 ppm high or low for a few hours to
> catch up or simply accept that there is an integer number of seconds
> difference in the times and corrective this during the next preventive
> maintenance the next year or some years from now. The absolute
> accuracy is not very important, it is much more important that all
> systems on the site have the same time and that the time is linear, so
> that the time _intervals_ are correct.
If you tell ntpd to use only slew mode, it will behave as you describe.
However, the problem is that, for expected accuracy better than some
fraction of a second, while the various machines are slewing, and until
they reach the step limit, applications must consider the network
unsynchronized.
>
> >The next version of NTP for the Interplanetary Internet will use
> >solar-system Barymetric Dynamic Time (TDB), not this UTC kidstuff. You
> >can compute TDB from Terrestrial Dynamic Time (TDT) from TAI,
> >ephemerides of the planetary orbits and masses of the Sun and planets,
> >corrected for relativistic effects. Mean solar time will be discontinued
> >along with leap seconds necessary to align UTC with TAI. The leapsecond
> >table will be replaced by suitable ephemerides tables necessary to
> >calculate TDB.
>
> These parameters should be transmitted in the timing message as is
> done with the GPS navigational messages (or in the lower precision
> values in the GPS almanac). Without a synchronous parameter
> distribution mechanism, maintaining such a system becomes a nightmare.
Yes, GPS is the intended model, but the delays are huge and connectivity
Thorsten Glaser
begin D. J. Bernstein scripsit
>Matthias Andree <matthia...@gmx.de> wrote:
>> Does sntpclock compensate for network latency?
>
>Of course.
>
>> Does clockspeed work on machines that crash or that are shut down
>> during the night without using the full-resynchronization scheme
>> around sntpclock?
>
>Yes. The best estimate of the clock speed is saved on disk. A single
>sntpclock reading after boot is enough to return to normal behavior.
The first sntpclock placed after the dial-in (for non-permanent lines)
and BEFORE the start of the clockspeed daemon I guess?
>> > > clockspeed does not synchronize,
>> > Sure it does, every time you run sntpclock. You can run sntpclock from
>> > cron if you want. The next version of clockspeed will have a simpler way
>> > to set this up.
>> Yes, but that "NTP client" propery is not clockspeed's, but
>> sntpclock's.
>
>Silly distinction. sntpclock is part of the clockspeed package. The
>sntpclock program is designed to work with the clockspeed program.
And the clockspeed pgm is part of the clockspeed pkg :)
I use clockspeed here on OpenBSD 3.0-current, although they do not
any more officially support it. I set my local time on my router/NAT
proxy to TAI/UTC (without POSIX mistake not to count leap seconds) and
for the sake of ease, my local time on my desktop box too.
My "real local time zone" here is CET-1CEST, and I set the time of
my remaining clocks (my wrist clock, microwave oven and mobile phone)
by adding 3600 seconds to the router's clock.
I beg you not to stop supporting OpenBSD. If you don't, I still have
the NTPD support in the kernel, which adds
* skewing (slewing?) support to stepping support
* setting the clock backwards in securelevel > 0
Maybe this could be of use for the next version?
Thanks in advance for any reply,
-mirabilos
--
end
C:\>debug
-e100 FA EB FD
-g
Thorsten Glaser
>Paul Keinanen <kein...@sci.fi> wrote:
Is there a public taiclockd server running which I can access from
europe so that I get the knownly right time? (Is taiclockd/taiclock
accurate wrt network latency?)