Thank you to everyone who replied. I haven't been able to reboot yet to
test, but I think the clock-frequency in /etc/sysconfigtab (see below)
was the culprit. The responses I received were:
* I recently had a problem with one of my main Firewall/NTP servers (an
Alpha
800). Turns out that there was a hardware clock problem. Compaq
service had to
replace the motherboard containing the TOY (time of year) clock then
everything
was a-ok.
* See if it helps to boot from the generic kernel
* My first guess would be a clock drift file of some sort. I seem to
recall
some OSes allow one to have a file defined that can allow the OS to
compensate
for the lousy accuracy of the system clock--- presumably that file was
correct
on the old server (which if uncorrected would gain 7 minutes per hour)
but
is now being applied to a more accurate system clock. A quick scan of
man pages shows that ntp does use a drift file (usually /etc/ntp.drift,
defined by /etc/ntp.conf). If you are using ntp, that is probably your
culprit. Didn't see any other references to a drift file for the clock,
but others might exist. I would see about setting the drift file to
have zero drift (ntp should automatically correct it, but may take a few
days to get right, possible longer depending on your setup).
* You could decide to use ntp to keep the time correct, but that wiuld
not really
solve your problem, just avoid the symptoms.
* Check your /etc/sysconfigtab file and see if you have a line like
the following in the generic subsystem:
clock-frequency = 1200
If so, just delete it and reboot.
Here's what's happening:
All Alpha systems EXCEPT the rawhide series (4100, 4000, 1200, etc) use
a clock frequency of 1024 Hz. The rawhides use a frequency of 1200 Hz.
The parameter "clock-frequency" is normally determined from the hardware
at boot time, and the system uses it to update the time. Every time the
clock interrupts, the system time is advanced by 1/(clock-frequency)
second.
In your case, the ES40 is interrupting every 1/1024 second. But because
clock-frequency is specified as 1200 in sysconfigtab, this overrides the
hardware setting, and the system time advances by only 1/1200 second
instead
of 1/1024 second. Over the course of one minute, the system time
advances
60*(1024/1200) = 51.2 seconds. So you lose about 8 to 9 seconds a
minute.
Now I'm sure you're wondering why clock-frequency is even being set in
sysconfigtab. The truth is, it shouldn't be; the parameter should be
effectively read-only (and in V5.0, it is) and it's not set in the
default
sysconfigtab. But what probably happened is that at some point on the
4100,
someone modified the generic subsystem with either sysconfigdb or
dxkerneltuner. This read the current values of all the parameters in
the subsystem and wrote a new stanza that explicitly set all of them in
sysconfigtab. So in effect, it hard-coded a clock-frequency of 1200 in
your /etc/sysconfigtab...which was fine as long as it stayed on a 1200
Hz
machine!
I've also seen this happen the other way: a customer copied a
sysconfigtab
with clock-frequency=1024 from an 8200 to a 4100. That system, of
course,
GAINED time in the same proportion as you're losing it.
Thanks again to everyone who replied!
Teresa
Teresa Biehler wrote:
>
> I need some help from the experts.
>
> We just put a few new machines into production. Rather than load the OS
> fresh, we restored / and /usr from backup onto a new drive and then this
> became the system disk in the new server. The old system was a 4100 and
> the new is an ES40. The problem is that we're loosing time on the new
> server - about 7 minutes per hour.
>
> In order to isolate the problem, we ran two tests:
> - Brought the system up in single-user mode with only / mounted.
> Checked the time (it was correct), waited about 40-45 minutes and
> checked the time. It was off by about 6 minutes.
> - Halted the system. Waited 20 minutes. Brought it up into single-user
> mode. Checked the time. It was exactly correct.
>
> We're having the problem on three new systems. The conversion process
> was the same for all three although the hardware is different on one of
> the new systems. I only was able to run the above tests on one system.
>
> Any ideas? Is there something in the kernel which impacts clock speed?
> Is there some difference in the hardware that needs to be accouted for?
>
> Thanks.
> Teresa
Received on Wed Mar 29 2000 - 15:13:57 NZST