[erlang-questions] : Subtle behaviour of Erlang scheduler
Ulf Wiger (TN/EAB)
Mon May 28 22:52:58 CEST 2007
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
(*) 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
> 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?
More information about the erlang-questions