Archive for January 27th, 2009
The number of daily visitors here rounds off to very nearly zero, so this spike from my Cabin Fever trip report stands out like a sore thumb:
The numbers are 118, 36, 10, 5, 4, 3. If you’re a geek, you’ll think of an exponential decay and it turns out that’s just about true: the time constant is 2.8 days and the equation pretty much works for the first four days, after which we’re into the Long Tail.
Most of the hits came directly from the EMC mailing list, with a substantial minority from Webbish sources like Gmail and various archives. There’s no way to tell how many people who subscribe to the list didn’t click on the link, although this provides a quick-and-dirty estimate of the folks interested in such things.
The counterweight gantry, laser aligner, and Y-axis bellows posts were also popular, at least to very small groups of people in the grand scheme of things. But if everybody showed up in the basement shop, I’d definitely have to move some stuff to make room!
I just tried compiling a program (for an Arduino) and make grumped about a date in the future:
make: Warning: File `Makefile' has modification time 1.4e+02 s in the future <<< usual compile output snipped >>> make: warning: Clock skew detected. Your build may be incomplete.
Turns out that the timestamps really were screwy:
[ed@shiitake Solar Data Logger]$ date Sun Jan 25 10:57:44 EST 2009 [ed@shiitake Solar Data Logger]$ ll total 28 drwxr-xr-x 2 ed ed 4096 2009-01-25 10:59 applet -rw-r--r-- 1 ed ed 1920 2009-01-25 10:35 Logger.pde -rwxr-xr-x 1 ed ed 7719 2009-01-25 10:59 Makefile -rwxr-xr-x 1 ed ed 7689 2009-01-25 10:53 Makefile~ -rw-r--r-- 1 ed ed 1880 2009-01-25 10:08 Solar Data Logger.pde~
Well, now, how can that be?
The offending files are stored on a file server, not on the machine in front of my Comfy Char. The current dates for the two machines weren’t quite the same: the server was running just slightly in the future.
I used an ordinary Kubuntu desktop install on our “file server”, which is basically a Dell Inspiron 531s running headless in the basement. All this is behind a firewall router, so I do not have an Internet-facing machine running X, OK?
Kubuntu has an option that updates the clock automagically, but only once per boot.
Right now, that box claims an uptime of just over 22 days. It’s run for months at a time without any intervention, which just one of the things I like about Linux:
uptime 11:07:08 up 22 days, 19:52, 1 user, load average: 0.00, 0.02, 0.00
I think you can see the problem: after three weeks the PC’s internal clock had drifted more than two minutes fast.
I used the Big Hammer technique to whack the server’s clock upside the head:
sudo ntpdate pool.ntp.org
[sudo] password for ed: youwish
25 Jan 11:01:22 ntpdate: step time server 188.8.131.52 offset -151.277185 sec
That’s 7 seconds per day or 151 seconds out of 2 megaseconds: 77 parts per million. It’s in a basement at 55 F right now, so there may well be a temperature effect going on.
You can set up ntp (www.ntp.org or, better, from a package in your distro) to run continuously in the background and keep the clock in time by slewing it ever so slightly as needed to make the average come out right. I just added an entry to /etc/crontab like this:
00 01 * * * root ntpdate north-america.pool.ntp.org
That way the clock gets whacked into line once a day when nobody’s looking.
If you’re running a real server with heavy activity, ntp is the right hammer for the job because you don’t want ntpdate to give you mysterious gaps of a few seconds or, worse, duplicate timestamps. Leap year is bad enough.
More about ntp at http://en.wikipedia.org/wiki/Network_Time_Protocol.
Memo to Self: set up ntp on the server and then aim all the desktops at it.
I used to do that when I was running a GPS-disciplined oscillator to produce a nearly Stratum 1 clock on my server, but then power got too expensive for that frippery.