Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

10.04.1992 - 

Test: X-Terminals im Netzwerk

Workstations kontra X-Terminals - den Gegensatz gibt es nicht

Die DV-Welt beginnt sich zu verändern: Wo bislang streng hierarchische Host-Terminal-Topologien vorherrschten, setzen sich vermehrt über Netzwerke verkabelte PC- und Workstation-Systeme durch. Für den Arbeitsplatz des Anwenders muß dies keine große Veränderung bedeuten: Auch in Zukunft wird er möglicherweise an einem Terminal sitzen. Grundlegender Unter. schied: Gegenüber den zeichenorientierten ASCII- beziehungsweise 3270-Terminals kann sich der Benutzer heute leistungsfähiger grafikorientierter X-Terminals bedienen.

X-Terminals im Netzwerkverbund mit leistungsfähigen Server-Rechnern sind heute nämlich sehr wohl eine Alternative zur etablierten Workstation-Umgebung. Das Zentrum für Grafische Datenverarbeitung e.V ( ZGDV) in Darmstadt führte, angeregt und durch Hardware unterstützt von der Tektronix GmbH aus Köln, quantitative Untersuchungen über die Leistungsfähigkeit von X-Terminals durch. Im folgenden sollen die Inhalte der Studie beschrieben und einige zusätzliche Aspekte im Zusammenhang mit X-Terminals diskutiert werden.

Dabei standen verschiedene Fragen im Vordergrund des Interesses: Wie viele X-Terminals verkraftet mein Server-Rechner? Wieviel Hauptspeicher muß ich für jede laufende Anwendung bereitstellen? Was bringt lokaler Speicherausbau in den X-Terminals? Wie stark wird mein Ethernet belastet? Wieviel Wartungsaufwand benötigt ein X-Terminal-Verbund?

Mit Laufzeittests verschiedener Software-Pakete - X-Performance-Tests, Dokumentverarbeitung, CAD-System, Daten-Visualisierung - wurden diese Fragen angegangen. Durch Einsatz einer konfigurierbaren Testumgebung konnten sowohl hardwarespezifische Parameter observiert wie auch das Verhalten der Software in unterschiedlichen Situationen bewertet werden.

Es fanden Tests in einer Diskless-Workstation-Umgebung mit zentralem Plattenserver statt - eine interessante Diskussionsgrundlage für die Bewertung, den Vergleich und die Kombination der konkurrierenden Welten.

Die Tests fanden im autarken Netz statt

Die Tests wurden in einem autarken Rechnernetz durchgeführt. Es stand ein Ethernet mit einer Übertragungsrate von 10 Mbit/sec zur Verfügung. Die X-Terminals (XP21, XP23, XP25, XP27, XP29) der Firma Tektronix wiesen im wesentlichen gleiche Leistung auf, unterschieden sich aber durch Eigenschaften wie Farbtiefe, Bildschirmauflösung etc. Die Anwendungsprogramme liefen auf einem in Leistung und Speicherausbau skalierbaren Server-Rechner (Solbourne 5/800); auf ihm waren auch die Boot-Dateien, Fonts etc. für die X-Terminals untergebracht. Weiterhin wurde ein Ethernet-Monitor (Tektronix TC) eingesetzt, um die Netzlasten zu messen und eine selbständig definierte Netzlast mit veränderbarer Paketgröße erzeugen zu können. Eine manuell bediente Stoppuhr ergänzte die Ausstattung.

Durch eine solche Zusammenstellung der Hardware war eine Konfiguration der wichtigsten Netzwerkparameter möglich. Parameter sind die CPU-Leistung des Server-Rechners, sein Hauptspeicherausbau und die Grundlast des Ethernets. Weiterhin beeinflußte natürlich die Anzahl gleichzeitig laufender Anwendungen die Geschwindigkeit des Gesamtsystems.

Für die Diskless-Workstation-Umgebung kam derselbe Server-Rechner zum Einsatz, dazu zwei Sun "IPC"-Systeme mit 8 beziehungsweise 24 MB sowie drei Sun-Workstations "SLC" mit jeweils 8 MB Hauptspeicher.

Die X-Performance-Tests wurden für jedes zu testende Gerät einzeln, bei unbelastetem Ethernet, durchgeführt, um möglichst gut reproduzierbare Resultate zu erzielen.

Die Anwendungsprogramme wurden unter Ausnutzung der Konfigurierbarkeit der Hardware fast allen möglichen Kombinationen der Parameter-Einstellungen ausgesetzt. Die Leistung des Server-Rechners variierte zwischen 27, 53 und 78 MIPS, sein Hauptspeicherausbau zwischen 32, 64 und 96 MB die Grundlast des Ethernet wurde in den Stufen 0%, 20%, 40%, 60% und 80% verändert und die Anzahl der gleichzeitig laufenden Clients variierte zwischen einem und fünfzehn (beim CAD-System nur bis zehn). Zum Test der X-Server-Implementationen wurden die frei verfügbaren Programme "x11perf" und "xbench" eingesetzt.

X11perf führt einen Einzeltest für fast alle durch das X-Protokoll verfügbaren Ausgabeoperationen durch. Die Ausgabe ist eine lange Liste, deren Inhalt zur gezielten Verbesserung einzelner Funktionen eingesetzt werden kann. Haupterkenntnis dieser Studie: Die eingesetzten X-Terminals erzielen aufgrund des eingebauten Grafikprozessors TMS 34020 in den Disziplinen Linienzeichnen (Standardbreite 0), Bitmaps/Pixmaps kopieren und Flächenfüllen im Vergleich zur Software-Lösung des MIT-X-Servers überproportional gute Resultate.

Xbench ist ein von Claus Gittinger, Siemens, erstelltes Programm, das zusammengehörende Funktionen in Gruppen zusammenfaßt. Für jede Gruppe wird dann aufgrund einer Gewichtung der einzelnen Meßergebnisse eine Kennzahl berechnet.

Alle gewichteten Meßwerte ergeben zusammen eine alles umfassende Kennzahl "xstones", die eine erste Einschätzung einer X-Server-Implementierung erlaubt. Die Kennzahlen stellen dabei einen Vergleich mit einer Sun-Workstation "3/50" mit X.11 dar, die definitionsgemäß 10000 xstones aufwies.

Allerdings ist Vorsicht geboten: Im Original des Programmes wird ein fehlerhaftes Script zur Berechnung der Kennzahlen aus den Meßwerten verwendet! Schon 1989 wurde von Chuck Adams, Tektronix Inc., ein Patch - dieser ist zum Beispiel beim ZGDV auf Anfrage erhältlich - veröffentlicht, der das Berechnungsverfahren korrigiert. Praktisch alle Veröffentlichungen enthalten trotzdem noch die Werte des alten Scripts, obwohl diese keinerlei Vergleiche der Endergebnisse erlauben. Als Beispiel sei hier die im allgemeinen veröffentlichte Zahl von zirka 20000 xstones für die Sun IPC angegeben Sie würde gerade einen Faktor 2 in der Geschwindigkeit gegenüber der Sun 3/50 bedeuten.

Die auf den eingesetzten Geräten gemessenen - korrekt berechneten - Kennzahlen sind in der Tabelle zusammengefaßt.

Je schneller der Rechner, desto schneller der Ablauf eines Programms. Je nach Anforderungsprofil einer Anwendung bringt aber eine Erhöhung der Rechnerleistung nicht unbedingt eine proportional kürzere Laufzeit. Wieviel CPU-Leistung man für eine gegebene Anwendung wirklich braucht, wurde anhand der oben erwähnten Beispiele Dokumentverarbeitung, CAD und Datenvisualisierung ermittelt.

Dabei liefen die Testsitzungen bei CAD und Datenvisualisierung ohne Verzögerung. Für die Dokumentverarbeitung je. doch wurde eine Testsitzung, in der Dokumente geladen, verändert und abgespeichert, Seiten geblättert und Texte formatiert wurden, in Realzeit abgespielt, das heißt mit simulierten Pausen zwischen den Benutzereingaben. Bei rechenintensiven Programmen wie zum Beispiel dem verwendeten CAD-System nimmt die Laufzeit linear mit zunehmender Rechnerleistung ab. Die Ausgabe der Daten auf den X-Terminals spielt dabei eine untergeordnete Rolle. Graphik-Geschwindigkeit ist zwar auf dem Bildschirm sichtbar, wirkt sich aber, auch aufgrund der asynchron abgegebenen Zeichenbefehle, nicht merklich auf die Gesamtlaufzeit einer Anwendung aus.

Das Datenvisualisierungssystem verhielt sich ähnlich wie das CAD-Programm. Hier allerdings wirkte sich die Geschwindigkeit des X-Ausgabegerätes auch auf die Laufzeit aus. Es wurden sehr viele Grafikbefehle in so kurzen Abständen abgegeben, daß sie die interne Queue des X-Servers überfüllten, wodurch die laufende Anwendung zum Warten gezwungen wurde. Diese Wartezeit ist jedoch relativ konstant im Gegensatz zu den ungefähr linear mit der Anzahl der Anwendungen steigenden Laufzeiten für Daten-Einlesen und Berechnungen, Sie wirkt sich auf die Gesamtlaufzeit also nur relativ wenig aus (vergleiche Abbildung 1).

Die Ergebnisse der Dokumentverarbeitung zeigten ein anderes Verhalten. Grund sind die speziellen Anforderungen des Echtzeit-Tests. Es wurde deutlich, daß die CPU-Leistung nicht der einzige begrenzende Faktor ist. Um ein nahezu unverändertes Laufzeitverhalten gegenüber einer Referenz-Sitzung zu erreichen, genügte eine Rechnerleistung von zirka 3,5 MIPS pro laufende Anwendung (inklusive Betriebssystemanteil). Stand sie zur Verfügung, wurde die Laufzeit trotz Erhöhung der Anzahl laufender Programme nicht verlängert. Wenn die Anwendungen allerdings nicht mehr in den zur Verfügung stehenden Hauptspeicher paßten, verlängerte sich durch Swapping die Laufzeit aller Anwendungen drastisch.

Der Hauptspeicherausbau des Server-Rechners

Zunächst wurde der Speicherbedarf der eingesetzten Software ermittelt. Eine Aufstellung zeigt die Tabelle 2:

Der Speicherbedarf des Betriebssystems wurde mit "/etc/ pstat -s" direkt nach dem Booten gemessen. Da die Tests auf einem eigenen Ethernet-Abschnitt durchgeführt wurden, waren keine NFS- oder Yellow-Pages-Prozesse gestartet. Es existierte nur ein Login-Prozeß für die Systemkonsole. Die gemessene X-Sitzung besteht aus zwei xterm-Fenstern, zwei xclocks (1 analog, 1 digital zur Anzeige des Datums), 1 xbiff (E-Mail-Signalisierung), ein xload (CPU-Auslastungsanzeige), dem Motif-Window-Manager "mwm" sowie einem xlogout-Button.

Erwartungsgemäß hatte der benutzte Server-Rechner mit dem Visualisierungssystem bei bis zu 15 Anwendungen keinerlei Schwierigkeiten, die Laufzeitunterschiede zwischen einem Hauptspeicherausbau von 96 und von 32 MB betrugen nur zirka 15 Prozent (bei 15 Clients) (vergleiche Abbildung 2).

Völlig anders verhielt sich das Dokumentverarbeitungs-Programm, das extrem viel ständig verfügbaren Hauptspeicher benötigt. Sobald der Server-Rechner mit Swapping begann, stieg die Laufzeit stark an. Die Daumenregel "dreimal soviel Swap-

-Space wie Hauptspeicher" gilt hier nicht mehr. Bei 10 Clients war mit 96 MB Hauptspeicher gerade noch sinnvolles Arbeiten möglich; es waren allerdings erst 136 MB virtueller Speicher belegt. Dies ergibt ein Verhältnis von 1:1.4!

Obwohl das CAD-Programm pro laufende Anwendung den meisten Platz im, virtuellen Speicher belegten war hier sogar mit nur 32 MB noch keine wesentliche Laufzeitverlängerung zu vermerken. Es zeigt sich also, daß das eingesetzte CAD Paket eine sehr hohe Lokalität aufweist, die es ermöglicht, mit relativ wenig Hauptspeicher auszukommen, selbst wenn der Bedarf an virtuellem Speicher sehr hoch ist.

Zurück zum Thema X-Terminals. Die zentrale Aussage dieses Kapitels dazu ist: Es muß unbedingt auf einen dem Anwendungsmix-, angemessenen Hauptspeicherausbau im Server-Rechner geachtet werden. Ein Mangel an Speicherkapazität behindert das Arbeiten aller Anwender.

Der I/O-Speicher als .General-Purpose-Speicher

Die eingesetzten X-Terminals verfügten über getrennte Grafik. und I/O-Speicher, die unabhängig voneinander aufgerüstet werden konnten.

Der Grafikspeicher enthält zum Beispiel geladene Fonts und muß im wesentlichen zur Benutzung von Backing-Store aufgerüstet werden. Backing-Store ist das - optional - vom X-Server unterstützte selbständige Speichern von Fensterinhalten bei Überdeckung durch andere Fenster. Der Bedarf an Speicher beträgt dabei (Anzahl der Pixel) (Farbtiefe in Bit) Bit für jedes Fenster. Eine Anwendung benötigt also bei einer Fenstergröße von 1000 X 1000 Pixel auf einem 8,Bit-Farbbildschirm etwa 1 MB zusätzlichen Grafikspeicher.

Der I/O-Speicher ist der General-Purpose-Speicher des X-Terminals, in dem zum Beispiel der X-Server läuft, aber auch die Netzwerkprogramme und das eventuell vorhandene interne Betriebssystem. Dieser Speicher muß gegebenenfalls erweitert werden, wenn im X-Terminal lokale Clients ablaufen sollen.

Zum Testen wurde ein Ethernet-Monitor benutzt, der einerseits die Netzaktivitäten observierte und andererseits eine Netzgrundlast, zum Beispiel 50, selbst erzeugen konnte.

Ermittelt wurden die durchschnittlichen Belastungen des Netzes im 1- bis 20-Sekunden-Mittel und die Spitzenlasten. Zu war dabei, daß die beobachten als X-Terminal-Konfiguration die Workstationumgebung ein gleichmäßigeres Belastungsprofil zeigte.

Es werden, über die gesamte Laufzeit eines Programms verteilt, relativ kleine Pakete verschickte während eine Diskless-Workstation jeweils beim Start das komplette Programm über das Netz anfordert.

Die Tests erbrachten überraschende Resultate. Die Ethernet-Last spielte im Bereich von 0 bis 80 fast keine Rolle für das Laufzeitverhalten der Anwendungen. Die unterschiede lagen durchweg unter 10 der Gesamtlaufzeit.

Relativiert werden kann dieses Ergebnis eventuell durch die Tatsache, daß die Netzgrundlast von nur einer Quelle erzeugt und nur einer Senke aufgenommen wurde.

Konzeptioneller Haken bei dem Client-Server-Modell

Das Client-Server-Modell des X-Window-Systems hat einen konzeptionellen Haken: Fast jeder Benutzeraktion folgt die Versendung eines "Events", also die Benachrichtigung der Anwendung über ein ausgetretenes Ereignis. Dazu zählen Tastatureingabe, Wechsel der Maus in ein anderes Fenster, Ver- oder Aufdecken eines Fensters und so weiter. Diese Benutzeraktionen bewirken also mindestens einen Prozeßwechsel. Einer Reaktion der Anwendung, durch die der X-Server aktiviert wird, folgt erneut ein Prozeßwechsel.

Wird der X-Server über Ethernet angesprochen, etwa in einem X-Terminal, stehen zwischen ihn, und der Anwendung zusätzliche Prozesse, nämlich die Netzwerksoftware- Zieht ein auftretendes Ereignis eine Kette von Reaktionen nach sich zum Beispiel Mausbewegung: Window-Manager deckt Fenster auf; X-Server verschickt deshalb Expose-Event; Anwendung stellt Fensterinhalt wieder her -, so ist eine Menge von Datenpaketen über das Netz zu verschicken. So akkumuliert sich eine nicht unerhebliche Verzögerungszeit.

Eine wesentliche Verbesserung bietet die Verwendung lokal im X-Terminal ablaufender Programme. Dafür kommen alle Programme in Frage, die nur mit dem X-Server kommunizieren.

Ein lokal laufender Window-Manager beispielsweise bringt schon deutliche Vorteile. Alle Tastatur- und Mauseingaben, die nicht bis zur Anwendung weitergereicht werden müssen, können direkt im X-Terminal bearbeitet werden. Menüs des Window-Managers brauchen nicht über das Netz geschickt zu werden. Ein stark belasteter Host macht sich nicht durch stockende Mausbewegung bemerkbar (ein durch Grafik-Ausgabe belasteter X-Server dagegen durchaus). ,

Weitere Programme, die als lokal laufende Clients die Netzwerktätigkeit reduzieren helfen könnten, sind "xclock", "oclock", "xdaliclock" (analoge/digitale Uhren), "xfontsel" (Font-Auswahl-Hilfe), "editres", "listres" (Resource-Manager-Programme), "xprop", xdpyinfo", "xwininfo" (Display-bezogene Dienstprogramme) und einige andere.

Auch lokal laufende Terminal-Emulatoren sind eine sinnvolle Ergänzung, die das Netzwerk entlasten. Durch sie können, zum Beispiel über eine telnet-Sitzung, zusätzlich Rechner im Netz benutzt werden, auf denen die X-Applikationen nicht installiert sind.

Der Phantasie sind hier fast keine Grenzen gesetzt. Es gibt allerdings noch einige Nachteile, die auch erwähnt werden müssen.

So benötigt jedes lokal laufende Programm Speicher, der real vorhanden sein muß, da ein X-Terminal keine Swap-Platte besitzt. Es wird beim Booten oder wahlweise beim ersten Aufruf über das Netz geladen. Außerdem wird im allgemeinen für lokal laufende Programme eine Lizenz vergeben; man kann also auch keine eigenen oder modifizierten Clients auf den X-Terminals installieren. Neue Versionen gibt es nur beim Hersteller.

X-Server-Erweiterungen bei Server und Clients

Im X-Window-System ist die Möglichkeit der Erweiterung, sowohl auf der Server- als auch auf der Client-Seite, vorgesehen. Die Erweiterung geschieht durch Einbinden zusätzlicher Funktionalität in den Server und durch Bereitstellen einer Funktions-Bibliothek.

Beide Teile arbeiten über eine Erweiterung des X-Protokolls auf dieselbe Art zusammen wie der ursprüngliche Server mit der "Xlib", der zugehörigen Library.

Da eine solche Erweiterung, im allgemeinen X-Extension genannt, ein Neubinden des X-Servers verlangt, muß eine gewünschte Extension vom X-Terminal-Hersteller mitgeliefert bzw. nachträglich installiert werden. Eventuell sind zum Betrieb auch zusätzliche Hardware-Ressourcen notwendig. Das kann ein vergrößerter Speicher sein, ein optionaler Grafik-Prozessor oder eine Hardware-Schnittstelle, zum Beispiel für Drucker oder zusätzliche Eingabegeräte neben Maus und Tastatur.

PEX ( Phigs plus Extension to X ) ist beispielsweise eine X-Extension, die deutlich höhere Performance des Ausgabegerätes erfordert, als dies bei einem "normalen" X-Server der Fall ist.

Die extreme Aufrüstung eines X-Terminals führt natürlich zu der Frage, warum diese aufwendige Hardware nur einem einzigen Benutzer zur Verfügung steht, und das auch nur zur Ausgabe von dreidimensionaler Grafik.

Die Aufrüstung einer Workstation mit einem schnelleren Prozessor kommt immerhin allen Prozessen auf diesem Rechner zugute.

Der Einsatz von X-Terminals in Rechnernetzen bietet die Chance, jedem Benutzer einen komfortablen Arbeitsplatz zur Verfügung zu stellen. X-Terminals benötigen zudem wenig Platz und nur eine Steckdose, sofern sie mit nur einem (Bildschirm-) Gehäuse auskommen.

X-Terminals sollten Minimalausbau aufweisen

Jeder Benutzer kann alle auf angeschlossenen Host-Rechnern bestehenden Ressourcen .nutzen. Die Konfiguration der X-Terminals sowie die Wartung des Gesamtsystems sind übersichtlich und damit einfach zu handhaben.

Diese Vorteile müssen aber durch ausreichenden Ausbau der Server-Rechner nutzbar gemacht werden. Besonders ein ungenügender Hauptspeicherausbau zieht aufgrund hoher Swapping-Aktivitäten große Verzögerungen nach sich. Bei größeren Server-Rechnern besteht aber meist eine einfache Möglichkeit der Leistungsverbesserung.

X-Terminals sollten einen gewissen Minimalausbau aufweisen, um reibungslosen, komfortablen Betrieb zu ermöglichen.

Dazu gehört die Option Backing-Store, also selbständiges Wiederherstellen von Fensterinhalten die durch Überdeckung oder durch Ikonisierung des Fensters nicht sichtbar waren. Für Backing-Store ist zusätzlicher Grafik-Speicher erforderlich (Hersteller fragen!).

Sehr sinnvoll ist daneben der Einsatz lokal laufender Clients. Insbesondere der Windowmanager ist hier zu nennen, der keine Netzwerk-Verzögerung mit sich bringt und dadurch deutlich an Attraktivität gewinnt. Die Verwendung anderer Windowmanager bleibt dabei weiterhin möglich.

Terminal-Emulatoren, zum Beispiel lokale "xterm"s oder über telnet-Sitzung, tragen ebenfalls zur Entlastung der Server-Rechner bei, die ja für jedes laufende Programm- zumindest virtuellen Speicher zur Verfügung stellen müssen.

Obwohl theoretisch der Einsatz möglichst vieler lokaler Clients wünschenswert ist, muß darauf geachtet werden, daß diese auch Speicher-Kapazität und Rechenzeit im X-Terminal verbrauchen. Wird ein X-Terminal immer weiter aufgerüstet, verringert sich der Kostenvorteil gegenüber den Workstations.

X-Terminals sind also in Umgebungen angebracht, in denen viele Benutzer etwa gleiche Anforderungen stellen, auf gemeinsame Daten zugreifen oder in denen sie auf Großrechnern laufende Programme benutzen. Zentrale Rechnerverwaltung bietet dabei den Vorteil erhöhter Datensicherheit.

X-Terminals mit anderen Aufgaben als Workstations

Diskless-Workstations sind für entgegengesetzte Anforderungen passend. Individuelle Gestaltung und einfachere Erweiterung der X-Umgebung durch frei verfügbare Software sowie die Möglichkeit der Korrektur von Fehlern in den Quellprogrammen sind im wesentlichen in Entwicklungsumgebungen gefragt, in denen die Anwender unterschiedliche Bedürfnisse haben. Hier ist auch meist ein ausreichendes Maß an Know-how vorhanden, um die kompliziertere Technik zu verstehen und zu nutzen.

Zudem sind die einzelnen Benutzer durch den Einsatz individueller Workstations voneinander abgeschottet, so daß sich CPU-intensive Anwendungen nicht gegenseitig beeinflussen.

Um einen reibungslosen Betrieb mit plattenlosen Workstations zu gewährleisten, ist ein möglichst großer individueller Hauptspeicherausbau anzustreben. Auch in der Workstation-Umgebung ist Swapping der am deutlichsten spürbare Grund für geringen Durchsatz. Zusätzlich wird durch Swapping die Netzbelastung drastisch erhöht.

Welche der beiden Rechnerumgebungen letztendlich die günstigere ist, hängt also von den individuellen Anforderungen ab. Auch die Kombination beider Welten kann eine Alternative sein, wenn leistungsfähige Workstations zur Verfügung stehen, die durch Anschluß zusätzlicher X-Terminals besser ausgenutzt werden können.