{ |one, step, back| } 1 of 1 article WikiSyndicate: full/short

When Clocks Go Bad   11 Jun 04
[ print link all ]
Message ruby-talk:103140 on the ruby talk mailing list mentioned problems with the sleep command interacting in strange ways with setting the clock. That reminded me of this story.

Way back when, I used to work on a data acquisition system that used an IRIG clock reader to timestamp our data samples. An IRIG clock works by reading a signal that sends the time once every second. Between the second ticks, the clock reader would interpolate the time down to the millisecnod level. This allows you to have several clocks on different systems all synchronized to the same clock signal.

Our system had to take a sample every 20 milliseconds, so every cycle we would calculate the time of the next cycle. When the current data cycle was done, we would just wait until that next scheduled time arrived to start the next cycle.

An IRIG clock reader is an interesting device. Normally it works really well, but occasionally (especially if there is noise on the clock signal line) it will misread the time signal. One particular reader we were using tended to misread a couple of bits in the minutes data with the result that for one second, the clock reader would add 30 minutes to the real time. When the next clock signal arrived a second later, the reader would start reporting the correct time again.

Jumping ahead was no problem. Our software just used the reported time and continued to schedule data cycles. However, when the clock jumped backwards, the next data cycle was suddenly scheduled for 30 minutes in the future. The result was that our system mysteriously stopped dead for 30 minutes and then just as mysteriously restarted as if nothing happened.

Time is a strange concept in computer programs. It is difficult to know what the exact time is while executing. Consider the following lines of code …

   t = Time.now                      # Line 1
   puts "The Current Time is: #{t}"  # Line 2

One would think that line 2 will print the current time. And most of the time we would be correct. But suppose I pressed the suspend button on my laptop between line 1 and line 2. It might be hours (or days) before line 2 prints out its now "out-of-date" time message.

When you are dealing with times in the millisecond range, there are all kinds of things that will pause your program from one line to the next. Interrupts, page faults, and time slicing all interact in interesting ways to make the concept of "time" in a program something of a challenge.

It wasn’t hard to fix our cycle scheduler to be well behaved, even in the face of uncertain time. And I learned a new respect for time in the process.

 

Formatted: 17-May-08 15:30
Feedback: jim@weirichhouse.org