[Haskell-cafe] Re: Timing and Atom

[Tom Hawkins]

On Tue, Dec 1, 2009 at 2:24 AM, Lee Pike <leepike at gmail.com> wrote:
> Tom,
>
> I have a (hopefully) easy question about timing and Atom in the use-case
> where you're handling all your own scheduling without relying on a RTOS
> (where you get preemption).  Suppose I want a rule to fire every 2ms.
>  Naturally, I'd want to set a timer.  But timers in Atom are based on the
> __global_clock, and the rate of the __global_clock is not a constant
> time-reference: it depends on the rule complexity of each rule as well as
> when rules are scheduled.
>
> So do you try to do do a WCET analysis for Atom-generated code running
> without an RTOS and tweak periods/timers based on that to get regular
> timing.  This is a hard problem if you have a lot of periods that are
> relatively prime (I'm assuming at Eaton, this is rarely the case).

In our application, the RTOS runs the Atom generated function in a
foreground task at 1KHz.  It turns out this is the only task the RTOS
has to schedule.  So in our case, __global_clock is accurate to about
1ms.  We only use an RTOS because we're stuck with a poor set of
development tools.  This scheduling could have been easily implemented
by polling a hardware counter.  This has the added benefit of easily
checking for execution overruns:

void main() {
  unsigned long long nextTime = 0;
  while (1) {
    while (hardwareCounter < nextTime);
    nextTime = hardwareCounter + delta;
    atomFunction();
    if (hardwareCounter > nextTime) reportExecutionOverrun();
  }
}

If you need greater timing resolution than what is provided by the
main loop, then I think the only option is to reference a hardware
counter.  But this will only allow you to tweak a control law or a
signal processing algorithm. It won't give you execution timing
guarantees.

This one limitation of Atom: everything has to be scheduled as a
function of a base period.  The trick is to select the right period.
Too course grained and computations will take too long.  Too fine
grained and you'll spend a lot of effort breaking up computations into
several tiny rules just to meet timing.  It's the same tradeoff ASIC
designers have when selecting a clock rate.

I never considered running Atom generated functions in an asynchronous
loop until you posted your "Atomic Fibonacci Server" example
(http://leepike.wordpress.com/2009/05/05/an-atomic-fibonacci-server-exploring-the-atom-haskell-dsl/).
 I'm curious how such a system would behave if it referenced a
hardware clock to enable and disable rules.  I can see how this could
be problematic for hard real-time, safety critical stuff.  But there
is a wide field of applications where this approach would work just
fine -- not having to worry about meeting a hard loop time would
certainly simplify the design.  Could some form of static analysis be
applied to provide the timing guarantees?