Re: Unix Time and Leap Seconds

Moe Trin wrote:
> On Sun, 24 Jun 2007, in the Usenet newsgroup comp.os.linux, in article
> <YdWdncWaU_Y1E-PbnZ2dnUVZ_rfinZ2d@comcast.com>, Jerry Stuckle wrote:
>
>> David T. Ashley wrote:
>
>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote
>
>>>> So they have to be adjusted. And even though NTP tries to speed up and
>>>> slow the clock - it's not perfect. And at times the clock WILL jump
>>>> forwards or backwards at least one second.
>
> The only time the clock will be jumping is a boot time, before any
> applications are running, as kernel time jumps from "zero" to what ever
> the BIOS is claiming. There is a mechanism in NTP where you can also
> SET the time, but this should only be done at boot time.
>

The only time when the system sets it automatically, you mean.

>>> What kind of events are you speaking of that might cause discontinuities?
>> It depends on a lot of things. Many systems do not have the necessary
>> hardware adjust clock speed.
>
> When was the last time you saw a hardware adjustment for clock speed?
> Not to many of us are using IBM Type 1 motherboards from 1985. The
> Pentium class motherboards often don't even have a separate oscillator
> module. with the interrupt source being the oscillator that is part of
> the RTC.
>

True.

>> So just like any clock, if it's running fast, it must be set back
>> sooner or later.
>
> This kernel is compiled to run the IRQ0 interrupt at 100 "ticks" per
> second (others use 1000 "ticks"), and that means the the divider is
> normally running at 18432:1. To _drift_ the clock into correspondence
> with "real" time, that division ratio is altered. As the crap crystal
> oscillator used as a timing source is accurate to +/-100 ppm, the
> division ration is periodically altered over the range of 18430 to
> 18434 to make it read something approaching the desired time. No big
> magic deal - and no "major" steps. It's just that the 1/100 of a
> second may vary by up to 54 microseconds. If your kernel is compiled
> for a 1000 Hertz interrupt, the kernel is already doing this shuffle
> step routine, as the divider is only programed to integers, and not the
> 1843.2:1 r quired with a perfectly set oscillator.
>
> Old guy

First of all, uncompensated clocks may or may not be 100ppm. I've got
one server, for instance, which is off more than 500 ppm. Several
others run in the 200-400ppm range.

You've come up with a lot of arguments. So you are saying you can
guarantee - WITHOUT QUALIFICATION - that the clock will NEVER be set
back while things are running?

I didn't think so.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Tue, 26 Jun 2007, in the Usenet newsgroup comp.os.linux, in article
<DOGdnZ68FraQCxzbnZ2dnUVZ_vOlnZ2d@comcast.com>, Jerry Stuckle wrote:

>First of all, uncompensated clocks may or may not be 100ppm. I've got
>one server, for instance, which is off more than 500 ppm. Several
>others run in the 200-400ppm range.

Not enough detail - the original PC design had (as noted) a simple
crystal controlled oscillator on the motherboard. To reduce costs
(someone has to adjust the trimmer on the motherboard). manufacturers
went to oscillators in a can - a hermetically sealed can shaped like
a 14 or 16 pin DIP - the oscillator vendor sets the internal trimmer
in manufacturing, and the motherboard manufacturer merely plus in this
device. These devices, available from vendors like Dale, Raltron,
Vectron, and US Crystal are quite cheap (under US$4 in unit quantities.
less than a third that when buying a thousand at a time) and nasty, but
are normally spec'ed at +/-100 ppm over 0-70C. Finally, to reduce
costs still more, the oscillator may be part of the "real time clock"
such as the Dallas Semiconductor family. I don't have spec sheets on
these, but expect their accuracy to be comparable.

>You've come up with a lot of arguments. So you are saying you can
>guarantee - WITHOUT QUALIFICATION - that the clock will NEVER be set
>back while things are running?

Of course not - I have absolutely no control over what your users may
be doing to your systems. One would hope that if you are subject to
various legal requirements with respect to dinking with the clock, that
you have trained your users appropriately. If not, it really is your
problem, not anyone else's.

Old guy

Moe Trin wrote:
> On Tue, 26 Jun 2007, in the Usenet newsgroup comp.os.linux, in article
> <DOGdnZ68FraQCxzbnZ2dnUVZ_vOlnZ2d@comcast.com>, Jerry Stuckle wrote:
>
>> First of all, uncompensated clocks may or may not be 100ppm. I've got
>> one server, for instance, which is off more than 500 ppm. Several
>> others run in the 200-400ppm range.
>
> Not enough detail - the original PC design had (as noted) a simple
> crystal controlled oscillator on the motherboard. To reduce costs
> (someone has to adjust the trimmer on the motherboard). manufacturers
> went to oscillators in a can - a hermetically sealed can shaped like
> a 14 or 16 pin DIP - the oscillator vendor sets the internal trimmer
> in manufacturing, and the motherboard manufacturer merely plus in this
> device. These devices, available from vendors like Dale, Raltron,
> Vectron, and US Crystal are quite cheap (under US$4 in unit quantities.
> less than a third that when buying a thousand at a time) and nasty, but
> are normally spec'ed at +/-100 ppm over 0-70C. Finally, to reduce
> costs still more, the oscillator may be part of the "real time clock"
> such as the Dallas Semiconductor family. I don't have spec sheets on
> these, but expect their accuracy to be comparable.
>

I haven't seen many in that price range (even in large quantities and
sealed) which are spec'd to within 100ppm. And those in the RTC are
definitely not within that accurate.

In fact, I haven't seen many PC's at all which drift less than 8.6
seconds/day. Sure, there are a few. But most I've seen drift at least
twice that.

>> You've come up with a lot of arguments. So you are saying you can
>> guarantee - WITHOUT QUALIFICATION - that the clock will NEVER be set
>> back while things are running?
>
> Of course not - I have absolutely no control over what your users may
> be doing to your systems. One would hope that if you are subject to
> various legal requirements with respect to dinking with the clock, that
> you have trained your users appropriately. If not, it really is your
> problem, not anyone else's.
>
> Old guy

No, it's not my problem at all. I don't write code which is dependent
on the clock always going forward (which is what started this whole thread).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================