On Tue, 10 Jan 2012 15:59:45 -0500 Michael Mol <mike...@gmail.com> wrote:
> > Servers with long uptimes should use ntpd, especially if it's apps > > timestamp data. > > Laptops and desktops should instead use ntpdate every one or few > > hours, that is more suitable for those machines (usually they only > > care about what the correct time is now). > > > > > > Wouldn't it make more sense to get the clock set correctly on bootup > with ntpdate, and then have ntpd keep things in line moving forward? > Otherwise, every couple hours, you'd have your cron'd ntpddate jumping > the clock around. I've had apps get stuck in infinite loops from > retrograde clocks, and having it happen at the wrong time during a > compile process has its own context-sensitive consequences. I suppose it all comes down to the quality of the RTC itself. Time keeping daemons were never written with clocks losing a few seconds an hour in mind (as such hardware is obviously horribly broken) This raises one of my long-standing beefs with clocks: For the price of an average burger I can buy a wristwatch from any old arb street vendor that is about three seconds a year out. But it is rather common to find server grade hardware costing three months wages with pathetic clocks inside. How come? The silicon in the cheap wristwatch will cost about 20 cents a pop and they pump them out by the millions. I'm still looking for a valid reason why crap clocks in expensive computers are still commonplace... -- Alan McKinnnon alan.mckin...@gmail.com
