[Haskell-cafe] Re: Timing and Atom

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?