[erlang-questions] : Subtle behaviour of Erlang scheduler

[Ulf Wiger (TN/EAB)]

Corrado Santoro wrote:
> 
> But this does not mean that, in my opinion, the Erlang 
> priority system has a serious flaw and should be rethought. 
> Probably, in a telecommunication system, priorities could not 
> be so important, but if you use Erlang in real-time embedded 
> environment (and it's argued that Erlang is for 
> soft-real-time systems),

Indeed, telecommunication systems are soft-real-time,
which means that it is sufficient to meet deadlines 
in a high percentage of the cases, but missing a 
deadline is not considered a fatal error.

Erlang shines in this regard, IMO, but in my experience,
process priorities don't do much to help in this type
of system. Thus the recommendation to use 'normal'
priority in the vast majority of cases.

What is important in a complex, massively concurrent
soft-real-time system, is a way of queueing jobs in
overload situations. In a hard-real-time system, 
you should never get into CPU overload, but in the 
types of system we build, not only must you be able
to handle it - you must be able to handle several
hundreds of percent overload without keeling over
(One of our requirements is that we should withstand
500% overload(*) without losing established calls.)
Also note that we must always handle emergency calls,
if at all possible, even when we are rejecting 
requests due to overload.

Rather than using process priorities here, we rely
on _job_prioritization_. We may employ perhaps a 
dozen processes to service a request, all processes
running on normal priority. The job itself is 
identified and prioritized according to type, e.g.

- initial setup request: rejectable
- emergency setup req: rejectable only as last resort
- hangup request: non-rejectable, but not high prio
- etc.

(*) Overload here meaning that the system is asked 
to handle more traffic than the maximum capacity. This
is solved by rejecting requests, which (again) is 
perfectly fine in a soft-real-time system, but not 
in a hard-real-time system.

Once this scheme is tuned, we typically run out of 
traffic generators before we're able to kill the 
system.

> such as automation or even robotics 
> (and this is our application field), priorities are 
> fundamental, together with correct or predictable behaviour 
> of the scheduler.
> 
> Unless we want to exclude Erlang from some *very 
> interesting* application fields....

If we can agree that the current priority scheme in
Erlang reflects its focus on soft real-time, as 
described above, we can probably also agree that 
this scheme is very different from what most real-time
environments, such as VxWorks and OSE Delta, use.

Aren't we then talking about supporting a much larger
number of priorities, rather than tweaking the 
semantics of the current scheme?

BR,
Ulf W