Nach der Einrichtung von Datenstrecken beziehungsweise bei der Umstellung in andere Datendienste tauchen oft Probleme auf. Hierfür werden vielfältige Meßmöglichkeiten angeboten. im wesentlichen jedoch zwei Gruppen: Monitorgeräte, die an der Leitungsschnittstelle messen, zählen und analysieren sowie Software-Tools, die in den angeschlossenen Rechnern ebenfalls messen, zählen und analysieren. Die Unterschiede liegen sowohl in den unterschiedlichen Ebenen, in denen die Daten ermittelt werden, wie auch in der Zielsetzung, die einerseits möglichst hohe Ausnutzung teurer Leitungen fordert, dabei jedoch andererseits Aspekte der Gesamtsystemoptimierung - wie zum Beispiel erträgliche Antwortzelten - auch in Spitzenlastzeiten berücksichtigen muß.
Den Anwender am Bildschirm interessiert hauptsächlich die Gesamtantwortzeit. Diese besteht aus den Anteilen.
- Leitungslaufzeit (und der prozedurabhängigen Elemente wie Overhead, Halbduplex/Duplex, Direktruf-Verbindungsaufbauzeit, Frame-Länge im Layer 2 beziehungsweise Paketlänge im Layer 3 etc.) und
- Verweilzeit in den Datenendeinrichtungen (Warteschlangentheorie, zum Beispiel Systemzeiten und Verarbeitungszeit im Anwendungsprogramm).
Ist die Rechnerverweilzeit sehr viel größer als die doppelte Leitungslaufzeit, so spielt die Optimierung der Leitungslaufzeit kaum eine Rolle. Für heutige CAD-Systeme ist beispielsweise typisch, daß eine Verringerung der Leitungslaufzeit durch Erhöhung der Übertragungsgeschwindigkeit über zirka 100 KBit/s zu grafischen Arbeitsplätzen keine nennenswerte Verbesserung der Antwortzeit bewirkt, da die Rechnerverweilzeit zu groß ist. Bei kaufmännischen Bildschirmarbeitsplätzen sind heute Übertragungsgeschwindigkeiten von 4800 oder 9600 Bit/s typisch: Beispielsweise 4800 Bit/s und vier Sekunden Antwortzeit bei Abruf eines Bildschirminhaltes. Dies zeigt, daß die Antwortzeit-Betrachtung zunächst wenig hilfreich ist, wenn es um optimale Nutzung der Datenleitung geht.
Hierzu sollen zunächst die beiden unterschiedlichen Betrachtungen an Beispielen verdeutlicht werden. Aus Rechner-System-Sicht ist bei heutigen Bildschirmdialoganwendungen der Halbduplex-Betrieb mit Primary-Secondary-Steuerung typisch. Von Bildschirm-Cluster-Seite (Secondary) kann dabei erst dann gesendet werden, wenn der Rechner (Primary) die Freigabe erteilt hat. In einem SNA-System geschieht dies zum Beispiel mit Receive Ready (Pollverfahren). Werden nur Polls gesendet, so wird null Prozent Nutzlast übertragen. Im IBM-Software-Tool Network Performance Analyzer (NPA) kann dieser Prozentsatz (% neg-poll) für eine Leitung von Minute zu Minute berechnet und am Netzkontrollbildschirm angezeigt werden.
Man kann also aus Systemsicht von Vollast auf einer Leitung sprechen wenn praktisch keine "unnützen" Polls mehr gesendet werden; das heißt, wenn auf jeden Sendeaufruf vom Rechner auch eine Nachricht vom Bildschirm-Cluster folgt. Dies kann auf Systemseite auch mit Traces ermittelt werden (Rechnerbelastung).
Der Vollast-Fall aus Datennetzsicht
Doch wie sieht dieser "Vollast-Fall" aus Datennetzsicht aus? Bedingt durch den Halbduplex-Betrieb können im gewählten Beispiel die Übertragungsrichtungen nur nacheinander gesendet werden; möglicherweise sind Hardware-Umschaltzeiten zu berücksichtigen. Die Messung an der Schnittstelle zum Datennetz zeigt daß auch Overhead zu berücksichtigen ist, wenn die Ausnutzbarkeit der Datenleitung betrachtet wird. Dazu wieder ein Beispiel:
Das Beispiel zeigt, daß die Leitung vom System - prozedurbedingt - nur zu 80 Prozent (halbduplex) genutzt werden kann.
Der 80-Prozent-Wert kann zu Überlegungen zur Systemoptimierung genutzt werden. Höhere Leistungsausnutzung kann zum Beispiel durch Multi-Multipoint (Bild 1) erreicht werden. Während noch nach A gesendet wird, kann von B schon empfangen werden.
Messung der Lastreserve
Bei der Lastreserve wird der Datenstrom richtungsabhängig analysiert und die Analyseergebnisse in mehreren programmierten Zahlern abgelegt (Bild 2).
Der Abgleich der Lastmessung an der Leitung auf die mit Softwarer-Tools ermittelten Werte erfolgt über den "100 %-Last-aus-Systemsicht" Wert, der über die neg.-poll-Zählung gefunden wird. Die Lastreserve an der realen Leitung ergibt sich nach Abzug der Retransmissions und der neg. pools vom Total-Wert. Der Retransmission-Zähler ist unmittelbar für die Performance-Betrachtung der Leitung verwendbar.
Eine Bemerkung zum Wissen über die betrachtete Last, die gemessen wird: In verteilten Systemen mit Routing ist es oft erforderlich, zur Beurteilung der Lastwerte zwischen verteilten Systemen die Routen beispielsweise die Anfangs- und Endpunkte sowie Details der Session (Status) für den Meßzeitpunkt abrufbar zu haben.
Die vorhergehenden Überlegungen erlauben noch keine Überleitrechnung von Standleitungen im Postnetz (HfD) auf Datenpaketverbindungen (Datex-P). Dazu sind drei Stufen sinnvoll:
- Messung der Lastdaten (in einer für das Paketnetz verwendbaren Form, zum Beispiel Transaktionszahl und Zeit-/Längen-Verteilung der Transaktionen).
- Bestimmung der daraus resultierenden Parameter für die Paketübertragung.
- Kalkulatorischer Gebührenvergleich Datex-P - HfD.
Nach dem derzeitigen Stand werden die Gebühren für HfD - je nach Nutzungsintensität - bis 1993 bis zum 2,77 fachen steigen.
Dazu ist zunächst wichtig, was gemessen wird:
- Brutto (mit Synchronisation-/ Idle-Charactern und Polling) oder
- Netto, da davon die Gebührenhöhe abhängt.
Bei Änderungen in den Datenanwendungen und im Terminalbestand ist eine Neuverteilung der Gebühren mit kundeneigenen Meßmöglichkeiten sinnvoll.
Ausblick
Können die Einzelmessungen so gestaltet werden, daß gleiche Aussagekraft zum Beispiel im SNA-Netz im Decnet oder im Transdata-Netz gewährleistet ist? Noch weiter geht die Forderung, standardisierte Performance-Messungen an Datennentzen durchzuführen. Ein erster Ansatz dazu ist der American National Standard X3. 102 - 1983, "Data Communication Useroriented Performance Parameters". Hier wird das Datennetz anwenderorientiert betrachtet Außer den üblichen Begriffen wie bit error prob., block error prob., werden zusätzlich etwa access time, incorrect access prob, block misdelivery prob. im Part A (Primary Parameters) und user fraction of access time im Part B (Ancillary Parameters) beschrieben. Voraussetzung zur sinnvollen Nutzung ist, daß auf Netzseite (wie bei CCITT) verbindliche Netz-Leistungsdaten, auch anwenderorientiert, festgelegt werden.
* Dipl.-Ing. Hartmut Fleck ist zuständig für das Design von Datennetzen bei der Bayer AG, Leverkusen.
Der vorliegende Beitrag ist entnommen aus: telak Telekommunikations GmbH (Hg): Orgatechnik Congress 84 Kongreß-Dokumentation 7/9, Overrath 1984, S. 331 - 340.