Re: hwclock problem with leapseconds - posix?



hi,

@Michael Black,

thks for your description on how to deal with hwclock,

hwclock works, i know, fine tuned it works very precise, i have! been
using it for many years with excellent results,

thus i'm used to a quite precise time,

with some - and especially one - bad point, i had to care for,

so a new idea, our firewalls are well, internet is near, use ntp,

research, plan for setup, good experiences with qmail, good set of
server tools announced by 'djb', why not use it,

installed clockspeed, played a little, and, oh, funny thing, my time
is wrong,

some research,

installed libtai, adopted leapseconds, played a little, and, oh,
funny,

now hwclock does weird things,

my fault??,

no!, a system where the correct (non posix) zonefiles are in a
subdirectory 'right' should be able to work with them,

and thats what i ask for, besides wanting to save time for others who
may step into the same trap and can find an explanation instead having
to investigate themself,

and my - my systems! - error is not! one leapsecond every few years,
it is 23 seconds on every boot cycle or every --systohc, and thats
just a fault, something that can be corrected,

atomic precision is not soooo urgent for most people, but if one can
get timeserver service why not use it,

and if one can get easy administrative tools for it why not use them,

and if there are problems beside the street why not resolve them,

one can even learn from those things,

it's funny that so many people try to help me change my mind,

while so few start to do concrete work on the analysis of the details
of the misbehaviour,

wondering,

helpless user,

*******************************

Drop the leapsecond issue, drop all this other stuff that I've never
heard of, and deal with the hardware clock.

Until you simplify the problem, you will never be able to ascertain
where the problem lies.

Don't fuss with anything or make any adjustments, but just keep checking it
over weeks with
hwclock --show
Record the times, comparing it with a known good time. In other words,
tune your shortwave receiver to a time station (ie one that serves
only as a time and frequency standard), or get out your "atomic clock"
that syncs every night to data sent out by one of those time stations,
and see how much difference there is. The longer you keep this
up, the longer the difference will be.

Now you can deal with that problem in various ways. Get a computer or
clock board that keeps better time. Fuss with the actual clock oscillator,
adding temperature compensation or perhaps insulation to keep it at a
constant frequency. A crystal oven, to keep the crystal and even
the oscillator at a constant temperature even when the computer is off
will help things too.

Of course, some of the issue isn't how constant the oscillator in
the hardware clock is, but whether it's adjusted properly in the first
place. If it's not right on the frequency it needs to be, then it
will always be a slow or fast clock. You thus have to have an oscillator
that can be adjusted, and the skill and tools to adjust it. A really
precise frequency counter would be the easiest, but you have to have
one that is far better than the preciseness that you want from the
hardware clock. And you will have to measure, adjust, measure again
and adjust. If you don't have that frequency counter, it's a far
more tedious process, because you have to make an adjustment, keep
track of how far off it is (and that will take time, since the
closer you get the more time it takes to get an accumulated error
that will appear) and then adjust again, hoping you didn't go too
far in the wrong direction. Likely you'll need to change the
variable element in the clock's oscillator to something that is
multiturn, so you can make the needed fine adjustments.

Or, as someone suggested, if there is a trend in the drift, ie the
difference between the hardware clock and the time from the time
station is constant with time, then you can get your system to adjust
with software to compensate for that constant trend. This is similar
to the previous paragraph, except instead of adjusting the hardware,
you are telling the software that the clock's oscillator is off, and
by how much.

Or, you can sync the hardware clock with a time standard on the internet.

But until you deal with this, you'll never come close to "absolute time".
And leapseconds won't matter one bit, because you won't be able to tell
whether the one second addition every few years added for the leapsecond
is a leapsecond because it's lost in the accumulated seconds that come
from the drift of the hardware clock. Like I said, I can accumulate 20
seconds in a few weeks, if I kept that going for years one second would
be an insignificant thing, compared to the thousands of seconds that
come from the hardware clock being off.

The rise of "atomic clocks" around the household is precisly because
of all this. In the old days, you'd have a clock or two and maybe a watch
around the house. You'd set them and didn't care about absolute, since
nobody needed that precision. But as digital equipment took over, it
became so easy to add a clock function, they added them, causing massive
numbers of devices around the house with clocks. You still mostly don't
need precision, but it nags at you because every single clock is at a
different time. You no longer know which one was set exactly on time,
and have no idea which one is keeping proper time but with a constant
offset. So you buy yet another clock, one that receives the standard
time station and syncs to it. Instantly, you have a clock that you
can rely on, no fussing. You don't need the precision, you just
need to know that it has the "proper" time. You can set all the
others from it, and any variation you know is the other clocks.

Unless you can keep proper time in your computer, any talk of "precision"
or "standard" time means nothing, since even when you set the clock
right on time, chances are good it will not be "exact time" some time
later.

Michael

.



Relevant Pages

  • Re: hwclock problem with leapseconds - posix?
    ... An extra second, the leapsecond, added every few years means nothing, ... and deal with the hardware clock. ... that can be adjusted, and the skill and tools to adjust it. ...
    (comp.os.linux.setup)
  • Re: [RFC] Kernel shared variables
    ... kernel to update the time every microsecond. ... For clock_gettimewith nansoeconds precision, ... or by locking the hardware. ... the low precision clock ids ...
    (freebsd-arch)
  • Re: [opensuse] adjtime in openSUSE 11.2
    ... My system clock tends to stray ... Since I run ntpd I don't worry about the hardware clock. ... HWCLOCK it says ... The Adjust Function ...
    (SuSE)
  • Re: fastest but pratical way to measure time
    ... is of measuring the time accurately ... The way I was thinking about it is to have a clock that measures on the edge ... If I do this then my precision is 1/M. ... Ofcourse is there was a "continuous" way to keep track of this time then it ...
    (sci.electronics.basics)
  • Rationale for wall clocks
    ... Access to wall time information of a process/thread. ... when their (CPU time) / ratio reaches a certain threshold. ... clock_gettime is a very nice interface with nanosecond precision ... in clockid_t which would perfectly fit an additional clock. ...
    (Linux-Kernel)