[ell-i-developers] Re: Fixed Priority + Round Robin Scheduler

  • From: Pekka Nikander <pekka.nikander@xxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Wed, 12 Feb 2014 21:40:21 +0200

[I'm answering in perhaps an even older-fashioned and grumpy style, where while 
quoting I'm cutting out those parts of the message that I'm not referring to, 
and keeping everything terse to the brink of being rude.  This is how mailings 
lists used to be 20 years ago. :-)]

> As we can separate the scheduler, we can also design the system so that 
> scheduler is replaceable. This way we can implement one scheduler now and 
> offer some alternatives later. The first should in my view be the FPPS as it 
> is simplest and allows us a quick route to release a complete self-standing 
> work.

Agree, other than that we discussed this briefly face-to-face with Ivan, and 
came to the conclusion that it is best first to implement simple one-priority 
round robin, and then extend it with a simple fixed priority extension.  That 
is, there will be a class of lowest priority threads that go round robin, and 
then maybe at most 7 higher priority classes, where there can be only one 
thread per priority class.  (Unless of course it turns out easier and simpler 
to support something more complicated, which *may* be the case.)

For the fixed priorities to be really useful (hard real time), we would need 
compile-time scheduling anyway, and we won't be ready for considering that for 
some time.  Compile-time scheduling would be possible, in theory, with e.g. 
LLMV and predictive-enough code for higher-priority threads, but that's almost 
a PhD topic as such.

Furthermore, I think the very first implementation should be scout's honour 
round robin, i.e. not preemptive, and then add preemption there.  If we can 
make preemption optional in a way that is easy and nice (not too much #ifdef 
ugliness), then we could support both scout's honour round robin and preemptive 
round robin, as compile- or link-time options.

>> Regarding tasks, I also wanted to ask if there is already some idea of the 
>> "average" number of tasks that are planned to be running on the Ellduino / 
>> Baselli / Flotelli?
> I think the big idea is to push nodes out to the extremes, where things 
> happen in the real life. Every sensor in a building would eventually have its 
> own ELL-i node and the number of tasks would be perhaps two or three. In the 
> meantime, while we are waiting for world domination, a single node might have 
> a number of sensors and things attached and we should expect something like 
> two to eight tasks.

I agree.  I think we will typically see two or three threads, occasionally 
more.  Most sketches will have two threads, one for Arduino sketch and another 
for handling the network traffic.  Some will have a third thread e.g. for motor 
control or some other such function.  The latter would benefit from higher 
priority, and therefore fixed priorities should most probably come pretty soon 
after round robin, even though they are more error prone from the programming 
point of view (starvation etc.).


Other related posts: