LD 2

For a college graduate, doing simple arithmetic is like being your own goddamn action movie. There are car chases, an enigmatic antagonist, a love interest, and plot twists out the wazoo.

Take my real life problem for example. The phone system at work keeps time, but it doesn't ever synchronize with an outside source, so like a wall clock or wristwatch, it will report whatever time you tell it and if it slowly starts losing time, there's nothing you can do but manually change it to the correct time again.

Naturally, this pisses me off. There's no way to get the phone system to call the USNO Naval Observatory (1-202-762-1401) to match itself to the official time for the United States government. So it can't verify with any legitimate time server.

Now, PBX switches have an option to allow a daily time adjustment, a hack older than ARPANET, that does little more than tell the switch "Every day at midnight, change the clock by adding or subtracting x milliseconds from it." This isn't perfect, but it will help tremendously, especially when your PBX system clock regularly loses as much as three seconds a day.

All PBX time features are in LD 2, which essentially translates to "load the system program that handles time", which means "I'm going to dick around with your clock." It looks like this:

>LD 2
. SDTA X Y

X is either 1 or 0. 1 if you want to add time to the clock every day, 0 if you want to subtract time. Y is a number, which will be multiplied by 100 to get the amount of time in milliseconds that the clock will change. If Y = 7, your clock will gain or lose 700ms at midnight.

How do you figure out what to put for X? Obviously, you want to use 1 if your clock is slow and 0 if your clock is fast. But how do you figure out Y? Here comes the math.

First, set the clock manually and record the exact time you did so. In my case, I synced the PBX switch on 2004-06-19 17:08:44, I knew at this exact instant that the clock was inaccurate by 0.0 seconds, right? I made this my first measurement, a baseline of sorts. Then I waited. The next day, the clock was off by a few seconds. I waited longer. For two weeks, I just slowly watched as the clock on the switch would change its value after the correct time by a longer and longer period of time. Six seconds. Ten. Fourteen. Twenty.

Eventually, I felt I'd let the clock drift off enough to take my next measurement. On 2004-07-06 13:09:24 it was 24 seconds slow at that instant. I wrote it down. And again, I waited. Then I took my third and final measurement. On 2004-07-15 13:30:38, it was thirty-eight seconds slow. (You can tell that I'm watching the correct time to see when the PBX clock catches up to the correct minute.)

So now I have numbers. But what to do with them? I wrote a quick little C application to figure out exactly how many seconds had elapsed between measurements. I could just count days on a calendar, but we're trying to be precise here.

Between the first and second measurement, 1,454,440 seconds had elapsed. Between the first and third, 2,233,314 seconds. (Check me on it. I dare you.) Now I have some ratios. 24/1,454,440 and 38/2,233,314. I want to know how many milliseconds I need to skew the clock every day to keep it somewhat accurate. You math nerds probably had this problem solved two paragraphs ago. Screw you.

If the clock loses 24 seconds for every 1,454,440 seconds that pass, that's a discrepancy of about 0.0000165 seconds per second. Seems insignificant, huh? Remember though that this tiny, tiny quantity gets compounded 86,400 times a day. Then think about multiplying it times 7. Then Times 365. You get the idea. The ratio should be as close to 0 as our hardware is physically capable of allowing. The closer it is to 0, the less frequently I'll have to resynchronize it.

So we need to know how many milliseconds to add per day, not how many seconds to add per second. So first we need to multiply that tiny bit by 86,400. It's 1.4257. Our clock loses, on average, 1.5 seconds a day!

We do the same for the third measurement, to see if the amount of time the clock loses ever stabilizes. 38 / 2,233,314 = 0.00001702. Times 86,400 = 1.4701. Our last measurement is higher, but it's still in the same ballpark. So if we can add about 1.47 seconds to the clock every day, it will keep better time overall.

14.7 seconds = 1,470ms, so do we use this number?

>LD 2
. SDTA 1 1470

Whoops! We're adding 147,000ms, or almost two and a half minutes every day! Gotta remember to divide by 100 first. We have to use whole values, so 14.7 must become either 14 (for a still slow clock), or 15 (for a sometimes fast clock). Thus, we've caught the bad guy, gotten the girl, and saved the system clock. This is what we punch into the PBX switch:

>LD 2
. SDTA 1 15

And that's the end of that chapter.