You are not logged in.

#1 2007-06-04 23:08:34

Convergence
Member
Registered: 2005-07-02
Posts: 377

Clock moving too fast... again.

I've had this problem before, I think...  Here is the thread:

http://bbs.archlinux.org/viewtopic.php?id=28538

The short version is that I added "clock=pit" to the kernel boot line in grub, and it worked until now.  The argument is still there in my menu.lst.  Is it possible that kernel developers actually used some code in the "default" clock timer in the "pit" clock, and transferred a bug?

Everywhere I read of clock skew problems, people mention the CMOS battery.  If you run a system almost 24/7 (I rarely turn off my computer) would it matter if the CMOS battery were dying?  I'm not sure about this, but I think that linux only reads the time from the CMOS when it boots up, and then it keeps track of time on it's own, so the CMOS battery would have no effect on the system time while the computer was running.

Right now, according to my clock radio (not pc related) it is 1602.  My taskbar clock says 1622, and when I run hwclock it says "Mon 04 Jun 2007 04:29:15 PM PDT  -0.020001 seconds".  So if I understand this correctly, my CMOS clock is actually ahead of my linux clock which is ahead of real time.

Any ideas or new information anyone?


It's a very deadly weapon to know what you're doing
---  William Murderface

Offline

#2 2007-06-06 21:36:38

normc
Member
From: Ottawa, Canada
Registered: 2004-06-28
Posts: 277
Website

Re: Clock moving too fast... again.

My time used to drift so I set up a cron job to sync to a time site ie "ntpdate time.nrc.ca" this is run daily and keeps my time accurate.


Norm

Offline

#3 2007-06-11 09:04:05

Convergence
Member
Registered: 2005-07-02
Posts: 377

Re: Clock moving too fast... again.

I'm probably going to have to do that, but it seems so hacky.  How often does the script run?  I would hate to abuse the server, but I'd have to do it fairly frequently to prevent problems with my computer;  Amarok crashes every time I update the time.

It seems like it might be a kernel problem.  Maybe I should file a bug report.  It would be difficult to narrow it down to a specific kernel version, if that is where the problem is. 

Out of curiosity, what kind of motherboard do you have?  I am using an nforce2 based motherboard.


It's a very deadly weapon to know what you're doing
---  William Murderface

Offline

#4 2007-06-11 15:55:55

normc
Member
From: Ottawa, Canada
Registered: 2004-06-28
Posts: 277
Website

Re: Clock moving too fast... again.

My mb is an asus p4pe. It used to do it when I was running that other operating system.


Norm

Offline

#5 2007-06-13 23:09:55

phildg
Member
Registered: 2006-03-10
Posts: 146

Re: Clock moving too fast... again.

Rather than run ntpdate in a cron job, you could simply run the ntpd daemon.

Offline

#6 2007-06-15 06:09:43

Convergence
Member
Registered: 2005-07-02
Posts: 377

Re: Clock moving too fast... again.

phildg:  Unfortunately ntpd is designed to give up if the clock skew is too drastic.  I don't know if there is a way to override that behaviour, but if someone knows of a way, I'll use it. 

Tonight I'm going to try leaving the computer off for a while to see if it is a battery problem.

Thank you for your responses guys.  Hopefully we'll figure this out.


It's a very deadly weapon to know what you're doing
---  William Murderface

Offline

#7 2007-07-25 13:49:13

Convergence
Member
Registered: 2005-07-02
Posts: 377

Re: Clock moving too fast... again.

I've tried booting with "noapic" in the grub kernel line.  Still too fast.


It's a very deadly weapon to know what you're doing
---  William Murderface

Offline

#8 2007-07-28 11:10:55

Convergence
Member
Registered: 2005-07-02
Posts: 377

Re: Clock moving too fast... again.

OK, I feel dumb, but I finally solved my problem.  I thought that dynamic overclocking was disabled, but my bios has 2 different locations where it can be enabled.  I found the second menu where it was enabled and disabled it, and my clock is pretty much perfect now.  I had "noapic" in my kernel boot loader line, but I think the proper argument is "apic=no" or something like that.  That probably would have solved the problem as well.

I think that this is technically a bug.  I've read several kernel bug reports that could actually be the same problem, but it gets kind of confusing because there were so many bugs with somewhat similar symptoms. 

I'm not marking this "resolved" because there is still a bug that hasn't been fixed yet.  As unlikely as it seems, this thread might get the attention of somebody that actually has the skills required to write a patch.  Thanks again guys.

I should throw in some info on my system.  It is an MSI k7n2 delta 2

Last edited by Convergence (2007-07-28 11:14:40)


It's a very deadly weapon to know what you're doing
---  William Murderface

Offline

#9 2007-07-28 20:51:24

Convergence
Member
Registered: 2005-07-02
Posts: 377

Re: Clock moving too fast... again.

Now it looks like my system crashes w/o dynamic overclocking.


It's a very deadly weapon to know what you're doing
---  William Murderface

Offline

#10 2007-08-01 01:01:04

Convergence
Member
Registered: 2005-07-02
Posts: 377

Re: Clock moving too fast... again.

I think it was an overheating problem, which I may have solved by cleaning out the PC.


It's a very deadly weapon to know what you're doing
---  William Murderface

Offline

Board footer

Powered by FluxBB