Re: Slow kernel clock
Seneca <seneca-cunningham@rogers.com> wrote:
> -snip- <
I was wondering about how to get the system clock to match the hardware
clock when the system's time is >5 min slow. I can't use the NTP clients
because of a rather ignorant windoze proxy (determined by trial and
error), and I would prefer not to have to manually set the time every
day or so (hwclock --hctosys).
-snip- <
Here are some ramblings from a "confused" mind :)
Everytime I have tried to manually use the hwclock program in Linux, I
have usually made things worse :( This is probably due to my own lack
of full understanding of what it does <g>. I only point this out to
make sure you are including the possibility that the use of "hwclock
-hctosys "might" be contributing to your problems too! This is NOT
meant to be accusitory... just to expand the possibilities you are
considering.
The way I currently understand how it works is that the hwclock program
can work both ways, i.e. Hardware Clock --> System Clock and System
Clock --> Hardware Clock. Normally the first is done on boot-up to set
the System Clock and the second is done on shut-down to re-set the
HWClock from the current System Clock settings. This works fine
providing your System Clock doesn't drift and is really a better
reference than the Hardware Clock. It would seem to me that any errors
aggregated during system "up-time" from activities like you mentioned
(excessive swap usage) could propagate into the Hardware Clock during
shutdown unless you had some way of compensating for the errors...
dunno. I guess you have already found this out from your post.
There are two different shell scripts in my Woody /etc/init.d that deal
with the hwclock program. One is "hwclockfirst.sh" which is run only on
startup and ONLY updates the System Clock from the Hardware Clock. This
seems to me to be ideal for what you want to do. The second is called
"hwclock.sh" and is run on startup AND shutdown. The latter is the one
that can propagate any errors accumulated in the System Clock back to
the Hardware Clock. All of these things are done automatically every
time you boot or shutdown. In addition to any manual updates you might
be doing. Be aware of these....
Here are some strategies I would consider:
1. Use the existing /etc/init.d/hwclockfirst.sh script to keep the
System Clock in synch with your Hardware Clock rather than the way you
are currently doing it. There are some cautions in the hwclock man
pages about doing this manually while the system is running. This is
probably where I got in trouble, but using existing scripts written by
the "experts" would seem to be much safer <g>. You should be able to
include this script in a CRON job...
2. This is from my admittedly weak memory... so use accordingly <g>. I
seem to recall that the NTPDATE "client" program would work without any
special ports being opened... specifically port 123. The NTP server
program, OTOH, required this port to be opened. It is possible that
your intervening M$ proxy would pass this un-noticed... dunno. Worth a
shot if you have not tried it already.
3. Do some snooping of the network on your side of the M$ Proxy and see
if there happens to be a time-server available. Many Universities and
local businesses (Banks??) have one for their "customers". If one is
there, you could use the NTP or NTPDATE programs on it and not worry
about the M$ Proxy.
4. Bug your ISP to either offer a time service or allow you to access a
public time server.
Just some thoughts... HTH.
Cheers,
-Don Spoon-
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: