On Fri, 26 May 2006, Mikkel L. Ellertson wrote:
Leon wrote:
"Lee Maschmeyer" <lee_maschmeyer@xxxxxxxxx> writes:
Hi all,
I have a dual boot system with FC5 and Windows XP. On FC5 I run ntpd
with the default config files. The drift file varies widely, from -0.4
or so to as much as -60 or 100 or more. Generally the longer Fedora is
up the smaller the number, though it's always negative.
But Windows is losing time hand over fist, maybe a couple minutes or
more in a 3-hour Windows session. I use an old program (AtomTime95) to
correct the Windows clock periodically but it doesn't do any permanent
good.
I had the same kind of thing happen with Fedora 4. It went away when I
installed Fedora 5 until I activated ntpd.
According to /var/log/messages Fedora has to set the clock back about
a second or so every time I boot it, but nowhere near the gargantuan
misalignment of Windows.
Does anybody have any idea how to make these two guys live happily
together sharing the clock? Yes, Fedora does use local time - at
least, that's the way I installed it..
Set UTC=false.
,----
| Setting UTC or local time
|
| When Linux boots, one of the initialisation scripts will run the
| /sbin/hwclock program to copy the current hardware clock time to the
| system clock. hwclock will assume the hardware clock is set to local
| time unless it is run with the --utc switch. Rather than editing the
| startup script, under Red Hat Linux you should edit the
| /etc/sysconfig/clock file and change the ``UTC'' line to either
| ``UTC=true'' or ``UTC=false'' as appropriate.
`----
You will have to double check, but running "hwclock --utc --systohc"
makes this change systems I have worked with. Running
"hwclock --localtime --systohc" will set it to local time.
With both Windows and Linux on the same machine, you probably should
have the hardware clock set to local time. Because the system time
is written back to the hardware clock when FC shuts down, you can
run into problem if it is not set correctly. If Linux expects UTC
and Windows expects local time, both end up doing large corrections
when they boot. You can end up with running corrections that are
based on an incorrect drift rate because you are trying to adjust to
the time zone difference every time you change the OS. You also run
into this problem when you change the hardware clock from local time
to UTC on a running system.
Switching back and forth between Windows and Linux in local time can still
mess up at the daylight time/standard time boundaries. Linux will adjust
for daylight time only if it is running. Windows always adjusts at the
next boot after the change. It's easy to construct scnearios where you
are suddenly an hour off in one direction or the other.
Depending on how much time you spend in Windows, you might like this
solution (which I use, but then I'm hardly ever in Windows):
Use UTC in Linux. Set the Windows time zone to GMT and turn off the
daylight-time adjustment for all users in Windows. Then Linux does
dalight time right and Windows won't screw it up.
Note that (I think) we've strayed off topic. The OP is talking about
drift of a few seconds or minutes at a time, not an hour or two or five or
six that you would expect from timezone errors. I know older kernels had
clock drift issues on some machines, but I thought that had been fixed for
some time now. If ntp isn't doing the job (surprising, unless somehow it
can't reach time servers or the drift strays too much too fast), then
maybe adjtimex can help.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
