Queuing – Warteschlangentheorie für Embedded-Software

Beispiel 3: Begrenzen der Interrupt-Last

Ein Hardware-Device sendet Interrupt-Anforderungen an einen Prozessor – zu willkürlichen Zeiten, aber mit einer mittleren Interrupt-Zwischenzeit von M = 25 Millisekunden. Die Interrupt-Service-Software benötigt eine mittlere Verarbeitungszeit A je Interrupt. Interrupts lassen sich nicht in einer Queue sammeln, ehe sie verarbeitet werden, daher gehen sie verloren, wenn zu viele Interrupts im Prozessor ankommen. Wie hoch ist der Wert A, der die Interrupt-Overload-Verluste auf unter ein Prozent begrenzt?

Hier haben wir es nicht wirklich mir einer Queue zu tun. Vielmehr werden die Interrupt-Daten in der Hardware gespeichert, bis eine Service-Software sie abholt oder ein weiterer Interrupt ankommt. Das Prinzip lässt sich mit einer Queue vergleichen, die eine Kapazität von genau einer Message hat, nur eben hardwarebasiert. Das heißt, wenn eine zweite Message ankommt, solange noch eine vorherige in der Queue ist, würde man das als Overload-Verlust betrachten.

Ziehen wir nochmal die Formel zum Berechnen der Wahrscheinlichkeit heran, dass mindestens K Messages in der Queue sein werden:

P [ > K enqueued ] = (R)

und setzen P auf weniger als 1%, wenn K = 2 oder mehr Messages für den Queue-Überlauf.

Das ergibt:

P [ >2 enqueued ] = R*R < 0,01

Und da R = A / M und M=0,025 Sekunden, erhalten wir
R*R = A*A / ((0,025)*(0,025)) < 0,01.

Ergebnis: A < sqrt (0,01)* 0,025 = 0,0025 Sekunden.

Die mittlere Verarbeitungszeit der Interrupt-Service-Software muss also weniger als 2,5 Millisekunden betragen, wenn wir die Interrupt-Overload-Verluste auf unter ein Prozent begrenzen wollen.

(ID:44833511)