Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Sun, 21 Nov 1999, amc wrote: > > thanks, Derek, for the mini-course on time ! NP :) > my /etc/adjtime contains: > 0.000000 938642353 0.000000 Ordinarily I don't like to quote manpages in messages (since it should be easy enough for the user to read them themselves), but since you don't have it, here's the relevant part of the discussion from the hwclock manpage: It works like this: Hwclock keeps a file, /etc/adjtime, that keeps some historical information. This is called the adjtime file. Suppose you start with no adjtime file. You issue a hwclock --set command to set the Hardware Clock to the true current time. Hwclock creates the adjtime file and records in it the current time as the last time the clock was calibrated. 5 days later, the clock has gained 10 seconds, so you issue another hwclock --set command to set it back 10 seconds. Hwclock updates the adjtime file to show the current time as the last time the clock was cali- brated, and records 2 seconds per day as the systematic drift rate. 24 hours go by, and then you issue a hwclock --adjust command. Hwclock consults the adjtime file and sees that the clock gains 2 seconds per day when left alone and that it has been left alone for exactly one day. So it subtracts 2 seconds from the Hardware Clock. It then records the current time as the last time the clock was adjusted. Another 24 hours goes by and you issue another hwclock --adjust. Hwclock does the same thing: subtracts 2 seconds and updates the adjtime file with the current time as the last time the clock was adjusted. Every time you calibrate (set) the clock (using --set or --systohc ), hwclock recalculates the systematic drift rate based on how long it has been since the last calibra- tion, how long it has been since the last adjustment, what drift rate was assumed in any intervening adjustments, and the amount by which the clock is presently off. I suggest you also see the manpage for adjtime -- you may need to install the adjtime package if you didn't. I assume Alpha Linux has this or else I suspect that /etc/adjtime would not exist. But maybe I'm wrong there... The first number is the most important one... it's the assumed drift rate. Yours appears to be zero, which means that the system should not adjust the system time. This is probably fine, unless there's something seriously wrong with your system's hardware clock. > i recently set up ntpd. > the only difference i note is the linux clcok is changing > (more than it used to) compared to the clock on my intel box. Unless you're talking about significant numbers (like more than a few seconds per day) this is fine... Intel's hardware clock isn't too accurate, which is the point of all that adjtime stuff in the rc scripts. It's trying to adjust the time to account for inaccuracies of the hardware clock. > it actually looks backwards ! > why should the hardware clock be _set_ by the system (linux) > that just _got_ its time from the hardware clock ? > but you're saying the algorithm is something like set the current time > to the ave. of the last 2 boots ? Yeah, I can see how you would think that, but if you think about it, it does make sense. At least on my system (intel) the first thing it does is set the system clock to the hardware clock, with the --adjust option. This adjusts the hardware clock to the drift rate, and then sets the system time. Since I use UTC time, it then does a second setting of the system time to change to UTC time. This clearly is not the most efficient method to do this, but in theory, this should work fine... In most cases, if you are not using UTC the first setting of the system time should be the ONLY one... Then again, I'm going on the intel rc scripts, yours may look completely different if you're on an Alpha. I can't say... I don't have one. <PONTIFY> I don't like the way redhat does this in their rc scripts, it could have been written more efficiently. Furthermore, I don't think they should do it AT ALL by default, since it presents the opportunity to really screw up a new user. But I have a lot of complaints about RedHat's rc scripts. Many of the ones I've looked at have been lazy hacks... </PONTIFY> -- Derek D. Martin Senior UNIX Systems/Network Administrator Arris Interactive derek.martin at ne.arris-i.com - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |