On Tue, Dec 1, 2009 at 2:24 AM, Lee Pike 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...). 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?