BONN (uk) - Welchen Einfluß haben Unterprogramme auf die Gesamtlaufzeit von großen Programmsystemen? Sind - etwa kurze Unterprogramme - bei Leistungskontrollen zu vernachlässigen oder wirken sie sich auf die Schnelligkeit von komplexen Softwaresystemen aus? - Diesen und ähnlichen - wir meinen praxisrelevanten - Fragen ging Udo Kelter, Diplomand an der Universität Bonn, im Rahmen seiner Informatikstudien nach. Er führte Messungen an Assembler-Unterprogrammen durch und entwickelte, da die üblichen Betriebssystem-Möglichkeiten genaue Messungen erst ab einer Größenordnung von etwa 50 - 100 Millisekunden erlauben, eine eigene Meßmethode. Mit Hilfe dieses Verfahrens können die zu messenden Zeiten, die um den Faktor 100 bis 1000 kleiner sein können als die erlaubten Betriebssystem-Zeitgrößen, durch "künstliche" Verlängerung in einen meßbaren Bereich gelegt werden. Die Methode wurde auf einer Siemens-Anlage 4004/151 unter BS 2000 entwickelt, soll aber anlagenunabhängig für ähnliche Praxisfälle anwendbar sein.
Heutige Betriebssysteme mit simultaner Bedienung vieler Benutzer müssen über ein Verfahren verfügen, mit dem sie die verbrauchte CPU-Zeit abrechnen. Dies funktioniert vereinfacht so: Bei der Zuteilung einer Zeitscheibe an einen Benutzerprozeß wird eine Stoppuhr gestartet. Nach Ablauf oder vorzeitiger Beendigung der Zeitscheibe wird die auf der Stoppuhr angezeigte Zeit auf das Zeitkonto des Prozesses aufaddiert. Die Anzeigegenauigkeit dieser Stoppuhr muß wenigstens den Bedürfnissen der Zeitabrechnung genügen. Bei Kostensätzen in der Größenordnung von 1 DM pro Sekunde ist daher eine Anzeigegenauigkeit von 1 bis 0,1 Millisekunden ausreichend. Will der Benutzer erfahren, wieviel Zeit sein Prozeß bisher verbraucht hat, so kann diese Zahl ermittelt werden, indem das Abrechnungsverfahren leicht modifiziert wird: Man liest die auf der Stoppuhr angezeigte Zeit ab und bildet die Summe mit dem bisherigen Zeitkonto des Prozesses. Die Zeitscheibe muß zu diesem Zweck nicht abgebrochen werden, das Zeitkonto bleibt noch unverändert. Diese Funktion kann entweder als Maschinenbefehl oder als Supervisor-Aufruf realisiert werden.
Nun ist man als Benutzer aber nicht nur daran interessiert, wieviel Zeit der gesamte Prozeß bisher verbraucht hat, sondern auch daran, wieviel Zeit einzelne Programmstücke verbrauchen. Als Programmstücke kommen zum Beispiel Unterprogramme, aber auch kurze Befehlsfolgen in Frage. Eine Zeitmessung ist nur so möglich, daß vor und nach dem Programmstück die bisher verbrauchte CPU-Zeit abgefragt und die Differenz der beiden Zeiten gebildet wird.
Dieser einfache Meßvorgang hat allerdings verschiedene Fehlerquellen. Die Bedeutung eines Fehlers hängt natürlich von seiner Größe ab, diese wiederum von der verwendeten Anlage. Hier wird von den Verhältnissen einer Siemens 4004/151 mit BS 2000 ausgegangen.
Messungen möglichst bei leerer Anlage
Die erste Fehlerquelle liegt in der Anzeigengenauigkeit. Diese ist unabhängig von der gemessenen Zeit. Ist diese nur wenige Zeiteinheiten groß, so kann der prozentuale Fehler spürbar sein.
Bei meinen Messungen lagen die Zeiten im Bereich von 50 bis 500 Mikrosekunden, während mittels des entsprechenden BS 2000-Features die verbrauchte CPU-Zeit nur in Einheiten von 100 Mikrosekunden abgefragt werden kann. Ein weit schwerwiegenderer Fehler rührt daher, daß während der Messung weitere Befehle ausgeführt werden, die gar nicht zu dem zu messenden Unterprogramm gehören.
In die gleiche Kategorie fallen auch Fehler, die durch Paging oder durch die Abarbeitung von Hardware-Unterbrechungen wie Kanalrückmeldungen verursacht werden. Bei sehr starker Belastung der Anlage können die Meßzeiten um einen Faktor bis 1,3 erhöht werden. Derartige Fehler sind vom Benutzer auch durch Anheben der Priorität nicht ganz unterdrückbar sondern eben nur dadurch vermeidbar, daß er bei möglichst leerer Anlage mißt.
Künstliche Verlängerung durch Wiederholungsschleife
Liegt die zu messende Zeit nicht im günstigen Bereich, so muß sie künstlich verlängert werden. Der einzige Ausweg ist, das zu messende Programmstück so oft zu wiederholen, daß die Gesamtmeßzeit in einem günstigen Bereich liegt. Bei beliebigen Programmstücken muß man dann am Anfang und am Ende passende Befehle zur Durchführung der Wiederholungsschleife einfügen. Es liegt hier nahe, das Programmstück als Unterprogramm aufzufassen, da ohnehin zum Beispiel Registerinhalte vor jedem neuen Lauf erneuert werden müssen.
Messung auf Null geeicht
Das Unterprogramm muß natürlich immer mit der gleichen Eingabe aufgerufen werden. Wenn das Unterprogramm die Eingabe verändert, muß zusätzlich die Eingabe vor jedem Aufruf erneuert werden. Hierdurch sowie durch die Bildung der Schleife entsteht ein neuer Meßfehler, denn die hierbei verbrauchte Zeit wird mitgemessen.
Diese Zeit wird am einfachsten mit Hilfe eines Dummy-Unterprogramms gemessen bei dem die Erneuerung der Eingabe in gleicher Weise erfolgt. Die gemessene Zeit wird von der Zeit, die für das eigentliche Unterprogramm gemessen wurde, abgezogen, womit die Messung sozusagen auf 0 geeicht wird.
Zeitscheibenwechsel und Paging verursachen Meßfehler
Die Größe einer Zeitscheibe ist 200 msek. Sobald soviel CPU-Zeit ununterbrochen verbraucht worden ist, unterbricht das Betriebssystem den Prozeß und entscheidet, ob die nächste Zeitscheibe dem eben noch aktiven Prozeß zugeteilt werden soll oder vielleicht einem anderen Prozeß, der auf eine Zeitscheibe wartet. Die Zeiten für diese Berechnungen gehen in die Messung mit ein und führen zu einem merklichen Meßfehler.
Meßgenauigkeit: Besser als 10 Prozent
Für die praktische Anwendung wurde diese Meßmethode in einem Modul realisiert, der einem zu untersuchenden Unterprogramm vorgeschaltet wird. Der Modul bestimmt den Wiederholungsfaktor automatisch so, daß die Zeit für die Hauptmessung zwischen 90 und 110 msek. liegt. Alle Probe- und Hauptmessungen erfolgen normalerweise innerhalb einer einzigen Zeitscheibe. Die Genauigkeit der Messungen war bei normalen Betriebsbedingungen besser als 10%, unter optimalen Bedingungen (leere Anlage) sogar bei 1% in einem Bereieh von 20 Mikrosekunden aufwärts bis etwa 10 Millisekunden.
Udo Kelter ist Informatik-Student an der Universität Bonn