Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Major Clock Drift



On Aug 30, 2004, at 9:27 AM, dsr at tao.merseine.nu wrote:
>
>> Thats over a full minute of drift in one week. I find that hard to
>> believe. Perhaps the RTC is inaccurate as a trade off for providing so
>> many ticks per second, but I've never seen a computer's clock drift
>> this quickly, even when we weren't running NTP.
>
> OK, it's magic pixies that have laid a curse on your computer.

Fine. I can believe that. Its about as likely as every other computer 
I've ever owned being blessed by magic pixies to have hyper-accurate 
clocks while everyone else over the last 20 years has been suffering 
from radical clock drift and I've never noticed. I believe your 
statements about the PC clock, and every website I've found says the 
same thing, but its empirically pretty clear to me that this hasn't 
been a problem on most computers I've used, even when they don't run 
ntp.

On Aug 30, 2004, at 10:07 AM, Jerry Feldman wrote:
>
> The bottom line is if you are doing some shared development, it is
> important to sync the shared systems otherwise code management systems
> and Make(1) have trouble.

Yeah, NFS, Make, and our source control (AccuRev) are all super grumpy. 
I started running ntpd, which has 'fixed' the problem.

I don't know if I can afford the time to leave the PC in CMOS, but 
checking hwclock should have the same effect, no?




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org