The first one is about method. When you try to determine the RTC drift with hwclock, the process can take quite some days. What criteria do we use to judge if the drift has been sufficiently determined?

I'll explain mine briefly, empirical as it is. I use the --debug option, and note the drift factor and the drift adjustment. When the first is giving a first decimal digit that fluctuates only narrowly, and at the same time the second has an absolute value well under 0.5s (and preferably close to 0.1s), I assume the drift determination is good enough.

Is there any test grounded/derived on the way hwclock works?

The second one is about Slackware's rc.S. According to hwclock(8):

rc.S doesn't do this, and there is probably a good reason. Any ideas?

TIA

Does the rcS call hwclock and not use any options? Or does it not call hwclock at all? And further, is your system time set without being on a network to benefit from NNTP? If so, then the RTC is being read somehow, just not from out of the rcS.

As far as worrying over the drift. I think you're reading too much into it.

My thinking, opinion/experience only; is that the hardware clock, your real time clock is NOT precise, it keeps time to some degree of precision, like losing one second per month/day/year, I forget and don't care too much ... an aside is there's at least one very lengthy thread in the forums I saw once about RTC precision, some very detailed answers. I also googled about RTC precsion at the time I saw that thread and agreed with the common points one can find on the web or see in that thread.

NNTP is the most precise. If you can use NNTP, then use it. If you have a RTC, then you have system clock at boot, before the network gets up and does any NNTP. A typical method I've seen instead is to boot up using the RTC, then use NNTP to get a more precise time, thus setting your system time to match what the atomic clock says, and finally using hwclock with the -w or --systohc (same result) switch. That one sets the RTC to the current system time, sort of the reverse of what you're doing when you set your system time from hwclock. And yes, the first call to hwclock uses the -s or --hctosys option to set the system time, because NNTP hasn't been performed yet, if ever. However the only true way to get precision is to use NNTP because the precision of the RTC is not going to be good.

I forget, but was surprised the the electronics could not even come close. In the reading I did, they talked about the precision of say a quartz watch, which is really a quartz crystal, and likely because the crystals are stable, and cheap maybe, where their properties don't vary too much with temperature, etc. However both the watch and the electronic RTC were ripped apart as being very un-precise in comparison to the atomic clocks.

1 members found this post helpful.

Hello pdi,

This has never worked correctly, and probably the reason Slackware does not use
hwclock's drift correction. For example adjtimex gives instructions to painstakingly
craft a good drift factor, and then tells you to turn ntpd back on, which will promptly
clobber the drift factor to zero. This is one example of what I meant when I commented
that the fragmented date-time documentation contradict each other. Hwclock attempts to
automate creating a good drift factor and it has never worked. Crafting a good drift
factor is a manual process(at least for now it is). This is all complicated by the fact
that there are two branches of hwclock, util-linux and BJH's original hwclock which he
still maintains. Documentation is written for each without distinguishing which one is
discussed and they each work differently.

Your question is one of the problems addressed when v2.26 is released, there are more.
You are fighting a broken system pdi. While it is possible to make date-time work on
with existing releases, it is an uphill battle and doesn't work very well. This is the
reason, that for decades now, when anyone complains of date-time problems the standard
answer has always been "Just turn on NTP and forget about it."

If you'll be patient I will explain how to make this all work when util-linux v2.26
is released.

1 members found this post helpful.

Slackware does a couple of things with the hardware clock. It reads it at boot to set the system clock (the software clock, run by interrupts) and it writes the system clock to the hardware clock on shut down. Otherwise, it's not twiddled or fiddled with.

Modern systems include a hardware clock chip that is, essentially, the same sort of thing that's in a wristwatch. It is kept "alive" by the CMOS battery on the motherboard, tick, tick, tick. The hardware drifts, not but much, but it does drift: leave the system turned off for a couple of weeks and it might drift by a second or two, maybe more seconds (they're not real reliable, close enough is close enough might be the rule).

You can, if so so choose, fiddle with it and control the drift (as described above) but that can turn into a career.

Thus, Network Time Protocol (NTP) was invented to keep notoriously bad timekeeping in check.

When you boot Slackware, the system clock is set to whatever time the hardware clock time is (it's a Good Idea, in my opinion, to keep the hardware clock on UTC and let software adjust the time when daylight savings happens and then when it goes away -- this varies by country and sometimes by region of a country and the software does the job for you of rolling forward and dropping back). No fiddling or twiddling on your part necessary. NTP is started late in the boot sequence (after the hardware clock as been read and set the system clock) and NTP will synchronize the system clock to a reference clock that references (somewhere down the line) to an "atomic" clock. NTP calculates network delay time for you and adds that delay into the system clock. It also evaluates the reference clocks you're using and replaces one or more of them with different ("better") references over time.

NTP keeps your system clock on time (close enough for government work anyway).

Shut down and the system clock time is written to the hardware clock, setting it to an accurate value that has been provided by NTP.

Fiddling around with a hardware clock to bring it in to pinpoint accuracy is an exercise in futility (read: a waste of your time). If you really must have dead accurate time (which you pretty much do with NTP), you can buy a radio or GPS clock to hang on your LAN and synchronize to that; however, you'll be synchronizing with NTP in any event. Keep in mind that you're not reading the hardware clock, you're reading the software clock -- the hardware clock is out of the loop.

So, bottom line, set your hardware clock to UTC, make sure you've got the correct time zone set, boot, let NTP start, wit about five minutes for it to synchronize and you've got the correct time.

Hope this helps some.

2 members found this post helpful.

rtmistler, Xsane, tronayne, thank you all for your time and input.

In order of appearance :-)

rtmistler, rc.S calls hwclock --hctosys, but not hwclock --adjust before it. I am aware of ntpd and use it on other hosts, but now I have a standalone test host, no networking at all, just for delving a little deeper into some aspects of Slackware. One of them turned out to be a test to see if Linux can tell the time without the aid of ntpd, as hwclock(8) and adjtimex(8) both claim.

Xsane, you have been very patient with my queries and I thank you for that. I appreciate the fact that determining the drift factor of both the hardware clock and the system clock is a manual process.
I also came gradually to realize how uphill the battle is; and I think I now have a fairly clear understanding of hwclock. It is adjtimex that still eludes me (this is a statement, not a call for help, yet). By your description v2.26 sounds quite ground-breaking, and I look forward to its release.

As a minor aside on your comments about the fragmented nature of the documentation, I wonder if the man pages for hwclock(8) and adtimex(8) could somehow acknowledge each other in an attempt to outline a workable flow of steps in the cases of standalone or intermittently connected hosts, which is their use scenario.

tronayne, your explanation is patient and lucid and I thank you for it. It is my fault I did not make clear the context of my question, and I apologize for this. This is an exercise for me to see if the time can be adequately kept in Slackware without using NTP and without installing any extra packages. It's not easy, but I have a feeling it can be done.

If anyone has any suggestions on the first question I would still welcome them.

That is because the file system is read only at that point and --adjust cannot be used.

At the time hwclock was added to rc.S the kernel was not automatically setting the
System Clock from the Hardware Clock. Hwclock had to be called there to facilitate
fsck, which has to be done read only. A catch 22.

Hwclock would had to have been called two more times after the file system was remounted
read write. I speculate that Pat did not bother with this because hwclock was broken, as
in the example I gave you previously that it clobbers drift factor to near zero when
used with ntpd, and would pointlessly slowdown the boot process.

This has all been resolved when util-linux v2.26 is released. You are wasting
your time trying to make this work with the current version.

These problems started the urban legend that Linux/Slackware users have only two
choices: one, run ntpd; two, live with horribly inaccurate date-time. Commonly summed
up as, "just run NTP and forget about drift correction."

That is nonsense. I have a machine that when running default Slackware 14.1 loses 3
seconds per day. Using the same machine with hwclock v2.26 after 3 months in continues
to have sub-second accuracy. Without drift correcting the Clocks it would have been 270
seconds fast. There is no reason to have systems perform that poorly. Even when running
ntpd, systems should be configured work reasonably well if ntp fails.

There are more docs then those two. I cannot speak to adtimex, but I do intend to
rewrite the hwclock man-page. I also want to write detailed documentation on how
to configure and use all the pieces of the puzzle. I don't know yet if that will be
part of hwclock(8) or a separate work. Before I do that there are more things to fix
in hwclock.
The answer to that is qualified, it varies with use case. Most applications should use
cold drift, which cannot be done with the current hwclock(fixed in the next release).
Generally, the best judge is the long term results of using a given value. If you are
picky enough a year long average is ultimate.

Had a thought (didn't hurt too much, either): if you've got a spare router or switch floating around, why not just buy a GPS or radio clock (they're not all that expensive any more). They're NTP compatible, generally have Ethernet connections (some have USB but I don't know about that) and you can just start your isolated box and sync it up to the clock with NTP and all your concerns about the hardware clock are moot. When you're done with the isolated box, simply hang the GPS/radio unit on your LAN and you've got a rock-solid NTP time source.

Hope this helps some.

tronayne,
I'd be mortified if I hurt you :-) It's a good suggestion which doesn't gravely violate the standalone-ness, thanks, I'll put it in my TODO list. As I explained, at the moment I'm on an ntpd-less diet, as an exercise. I appreciate your relaxed and solid knowledge, a true Slacker :-)

Xsane,
Without a wish to be biblical, what springs to mind is "eyes that do not see". I've made a tree diagram of rc.S to understand it better, and have been looking at the position hwclock is called, for days on end, and yet the simple truth is I didn't see it. Thanks for pointing this out to me.

I couldn't agree more.

Well, this is the spirit of my wish. I'm not set on man pages, but the end user would be much helped if able to find somewhere a coherent description of ntpd-less timekeeping. I would gladly contribute my notes on hwclock towards that end, however half-baked.

I'm itching for two questions, but I'll leave you in peace to get on with more important work. You have whetted my appetite for v2.26 to no end, and if I still remember them after its release, I'll come back as a bad penny :-)

Once more, thank you for your time.