Anforderungen an eine Client/Server- Konfiguration für das

Anforderungen an eine Client/Server- Konfiguration
für das „Online-Publishing“
S. Olbrich, H. Pralle, L. Grüneberg
RRZN/RVS Universität Hannover
Schloßwenderstr. 5, 30159 Hannover, Germany
E-Mail: [email protected]
1 Einleitung
1.1 Übersicht
Neue Anwendungen der rechnergestützten Kommunikation stellen häufig besondere Anforderungen an Kommunikationsnetz und eingesetzte Arbeitsplatzrechner. Sie bieten daher die
Möglichkeit, die Architektur der beteiligten Hardware- und Softwaresysteme im Licht der
neuen Anforderungen zu messen und zu bewerten.
Im folgenden beschreiben wir eine Anwendung aus dem „Regionalen Testbed“ (RTB)-Nord
des DFN-Vereins [Pra94]. Im Rahmen der DFN-Testbeds sollen neuartige Dienste der Breitbandkommunikation im Wissenschaftsbereich entwickelt und auf ihren Nutzen hin untersucht
werden.
1.2 Ein einfaches Modell
Zur Anwendung Online-Publishing wird im folgenden zunächst ein Szenario definiert, um
davon ausgehend, an einem abstrakten Prozeß- und Datenflußmodell eine System-Analyse
durchzuführen. Zu den in diesem Zusammenhang betrachteten Problemkreisen gehören
• Klassifikation der Medientypen,
• Qualität der Repräsentation und Präsentation,
• Untersuchung von Datei- und Datenstrom-Formaten,
Standards, Referenzmodellen sowie Transport-Protokollen.
Aus den prinzipiell im Hinblick auf das Online-Publishing darstellbaren Szenarien wurde zum
Zwecke der weiteren detaillierten Untersuchung ein beispielhaftes ausgewählt. Dabei handelt
es sich um ein Abfrage-System für Multimedia-Dokumente. Das zugehörige System-Modell
ist in der folgenden Abbildung dargestellt (Abb. 1).
Die Interaktion des Anwenders eines solchen Systems läuft in den folgenden Schritten ab:
1. Aktion:
Der Anwender fordert ein ausgewähltes Dokument an. Üblicherweise wird
dies durch Tastatur- oder Maus-Tastendruck initiiert.
2. Steuerung: Der Client-Prozeß fordert über ein Steuerungsprotokoll beim Server-Prozeß
eine Repräsentation des gewünschten Dokuments an.
3. Transport:
Der Server-Prozeß liest das Dokument aus der gespeicherten Repräsentation
und sendet diese dann über einen Datenkanal mit Hilfe eines DatenstromProtokolls an den Client-Prozeß.
4. Rezeption:
Die übermittelten Datenströme werden im Client-Prozeß in eine präsentierbare Darstellung überführt, um über die damit angesprochenen Sinnesorgane
des Rezipienten wahrgenommen werden zu können.
(2) Steuerung
Server
(1) Aktion
Client
(3) DatenTransport
DokumentRepräsentation
Rezipient
(4) Präsentation/
Perzeption
Abb. 1: Abstraktes System-Modell eines Multimedia-Abfrage-Szenarios
Das Prozeß- und Datenfluß-Modell wurde stark vereinfacht und abstrahiert, um die technischen Anforderungen an den wesentlichen Schnittstellen exakt spezifizieren zu können. Der
in einem vorausgehenden Schritt erforderliche Einspeicherungsvorgang wurde aus der
Betrachtung ausgeschlossen, da dieser für den lesenden Online-Zugriff nicht relevant ist.
Insofern erfolgte die Modellbildung im wesentlichen aus Sicht des Konsumenten.
2 Klassifikation der Anforderungen
2.1 Medientypen
In den bis heute nach dem Kenntnisstand der Autoren veröffentlichten Klassifikationen von
Medientypen bzw. Multimedia-Systemen werden häufig nur jeweils gewisse Schwerpunkte
betrachtet. Ein allgemein gültiges Klassifikationskonzept liegt derzeit nicht vor [DFN92,
Stein93]. Daher wurde hier versucht, einige Attribute mit gewissen Modifikationen und
Erweiterungen in einer möglichst orthogonalen Anordnung zusammenzufassen. Diese ist in
der folgenden Tabelle 1 dargestellt, wobei in den beispielhaft angegebenen Eigenschaften
diejenigen des Medientyps Rasterbild hervorgehoben sind.
Tabelle 1: Attribute zur Klassifikation von Medientypen in Multimedia-Systemen
Attribute
Beispiele
Sinneswahrnehmung
visuell, akustisch, haptisch/taktil
Räumliche Dimension
0, 1, 2, 3
Zeitliche Dimension
0, 1
Semantik/Abstraktionsgrad
für Graphik: Level gemäß CGRM
(Logical/Physical Level)
Organisation
flach, Hyperlinks, ...
Struktur
Sequenz, indizierte Sequenz, Baum, Matrix, ...
Transformation von ...
... anderen verwandten Medientypen
(visuellen Medien höherer Abstraktionslevel)
Quellen
Scanner, Mikrofon, Tastatur
Senken
Bildschirm, Lautsprecher
Metaphern/Paradigmen
„Buch-Paradigma“
Primitive/Elemente/Atome
Buchstabe, Vektor, Pixel, Note, Sample
QuellenCodierung/
Qualität der
Repräsentation
Wert-Diskretisierung
1–36 Bit/Pixel
Orts-Diskretisierung
72–2540 Pixel/inch
Zeit-Diskretisierung
8000, 44100, 48000 Samples/sec
Kompression
ohne Kompression,
verlustlose Kompr.-Verfahren (RLE, LZW),
verlustbehaftete Kompr.-Verfahren (JPEG)
Tabelle 1: Attribute zur Klassifikation von Medientypen in Multimedia-Systemen
Attribute
Beispiele
Relationen zwischen Medien
Required
Quality
of Service
Zeitliche, örtliche, inhaltliche Synchronisierung
Burst Rate
10–24 Mbps
Delay
0,2–2 s
Jitter
Error Rate
0
für geometrische Graphik: CGM, PostScript
für Rasterbild-Graphik: IPI/IIF, TIFF
Related Standards
Die weitere Betrachtung beschränkt sich wegen des relativ hohen Rezeptionspotentials und
den damit verbundenen hohen technischen Anforderungen auf visuell rezeptierte Medien.
Aus praktischen Gründen konzentriert sich die Untersuchung auf den Medientyp Rasterbild. Für eine gegebene Präsentationsqualität sind hier Maximalwerte für Speicher-,
Rechen- und Zeit-Aufwände spezifizierbar; daraus resultiert u. a. auch die besondere Eignung für den Echtzeitbetrieb. Bedingt durch den gerätenahen Abstraktionslevel ist der CPUBedarf je Primitive (hier: Pixel) relativ gering, so daß eine hohe Ausnutzung des TransportKanals zu erwarten ist.
2.2 Qualität der Repräsentation von Dokumenten
Die Repräsentation, d. h. die Abbildung des realen Mediums Bild in eine approximierte
digitale Darstellung erfolgt i. a. durch die sogenannten bildgebenden Systeme, wie z. B.
Flachbett-/Trommel-Scanner sowie digitale Kameras mit Zeilen- bzw. Flächen-CCD-Elementen. Dabei werden folgende Forderungen gestellt:
•
Bei der Abtastung sollte eine hohe Orts-Auflösung bei großer Scan-Fläche erzielt werden.
•
Die Diskretisierung der Abtastwerte sollte mit einer hohen Intensitäts-Auflösung („Farbtiefe“) erfolgen.
•
Es ist auf eine hohe Farbtreue zu achten.
•
Das abzubildende Objekt sollte geringstmöglich mit Strahlung (im sichtbaren, Infrarot- und Ultraviolett-Bereich), Temperatur, Druck und Reibung beaufschlagt werden.
•
Die Aufnahme des Objektes sollte in kurzer Zeit erfolgen.
In der folgenden Tabelle 2 sind die Auflösungen im Orts- und Werte-Bereich für einige
gebräuchliche Rasterbild-Eingabe-Geräte (Scanner) aufgeführt. Die Auflösungswerte in dpi
beziehen sich auf eine Vorlagen-Größe im DIN-A4-Format (210 mm x 297 mm). KameraScanner führen je nach Abstand zum Objekt eine Skalierung durch; konstant bleibt dabei
stets die Pixel-Anzahl. Kleinere Objekte können daher mit höherer Auflösung gescannt
werden. Dagegen ist bei Flachbett- und Trommel-Scannern die Auflösung konstant.
Tabelle 2: Orts-, Wert-Auflösung und Datenvolumen(unkomprimiert)/Bild (Scanner)
Pixel-Anzahl
Fläche
[mm x mm]
Auflösung
[dpi]
Farbtiefe
[bit/pixel]
Volumen
[MByte]
DIN-A4-400-dpiFlachbett-Scanner
3308x4676
210x297
400
24
44,2
Trommel-Scanner
177165x177165
500x500
9000
24
89800
Kamera-Scanner
(Flächen-Chip)
2048x2048
z. B. 297x297
z. B. 175
24
12
Eingabe-Gerät
2.3 Qualität der Präsentation auf dem Client-Sytem
Die Präsentation, also die Darstellung zur Aufnahme durch den Rezipienten, erfolgt üblicherweise auf Bildschirmen oder Druckern; dies sind Graphik-Ausgabegeräte, welche
rasterbildorientiert arbeiten. Dabei stellen sich die folgenden Forderungen:
•
•
•
•
Hinsichtlich der Ortsdiskretisierung sollte eine hohe Orts-Auflösung bei großer Präsentationsfläche
angeboten werden.
Im Hinblick auf geringstmögliche Fehler bei der Wertdiskretisierung sollte mit einer hohen IntensitätsAuflösung („Farbtiefe“) gearbeitet werden.
Insbesondere im Fall von Geräten mit geringer Orts-Auflösung (z. B. Computer- oder Fernsehmonitore
mit max. ca. 100 dpi) und Halbtonfähigkeit sollten Antialiasing-Verfahren eingesetzt werden.
Der Bildaufbau sollte in kurzer Zeit erfolgen. Die hier implizierte Verzögerungszeit resultiert aus den
Kontroll- und Datenströmen, den Dokumentespeicher-Zugriffsmechanismen und den Verarbeitungsschritten in den Client- und Server-Prozessen.
Beispielhaft seien in folgender Tabelle 3 die Auflösungen im Orts- und Werte-Bereich einiger gebräuchlicher Rasterbild-Ausgabe-Geräte (Bildschirme, Drucker) genannt.
Tabelle 3: Orts-, Wert-Auflösung und Datenvolumen(unkompr.)/Bild (Ausgabe-Geräte)
Fläche
Auflösung Farbtiefe
[mm x mm]
[dpi]
[bit/pixel]
Volumen
[MByte]
Ausgabe-Gerät
Pixel-Anzahl
Fernseh-Monitor
(CCIR Rec. 601)
Luma: 720x576
Chroma: 360x576
z. B.
408x306
z. B.
45x48
24
0,79
PC/Workstation
mit 19“-Monitor
1280x1024
298x238
109
1–24
0,16–3,75
DIN-A4-300-dpiLaserdrucker
2481x3507
210x297
300
1
1,04
DIN-A0-300-dpiFarbtintenstrahldr.
10200x13890
863,6x1176
300
4x8=32
540
Wünschenswert ist eine erheblich höhere Bildschirm-Auflösung, wie dies in Pilotstudien
gezeigt wurde [Comp94, Kröm94a, Lie92].
2.4 Standards für Datei- und Datenstrom-Formate und Kompressionsverfahren
Für den hier primär betrachteten Spezialfall Rasterbild-Graphik sind zahlreiche Normen,
De-facto- und Industrie-Standards für Dateiformate, Datenstrom-Protokolle und Kompressionsverfahren relevant, auf die an dieser Stelle nicht eingegangen wird [Olb95].
3 Realisierungsaspekte
3.1 Arbeitsplatzrechner
Bei den heute verfügbaren Arbeitsplatzrechnern, die für die hier diskutierte Anwendung
aufgrund der hohen Leistungsanforderungen geeignet sind, handelt es sich i. w. um RISCbasierte Workstations der Firmen HP, IBM, SGI und SUN. Die jeweils installierte Graphikhardware unterstützt üblicherweise Auflösungen von mindestens ca. 1280x1024 Pixel mit
einer Farbtiefe von 8–24 bit. Die angeschlossenen Farbmonitore bieten eine BildschirmDiagonale von ca. 19–21 Zoll, also eine Auflösung von ca. 72–120 dpi.
Als Anwendersoftware für das Online-Publishing sind z. B. die De-facto- bzw. Industriestandard-Internet-Werkzeuge WWW (World Wide Web), Gopher, WAIS (Wide Area Information Server) und Hyper-G, jeweils mit den zugehörigen Viewern (z. B. xv, display,
ghostview, mpeg_play) im Einsatz. Diese setzen auf den folgenden in den meisten UNIXBetriebssystemen angebotenen Application Programmer Interfaces (APIs) auf:
• UNIX-Datei-I/O: open, read, write, close, lseek, zum Teil auch mmap.
• Netzwerk-Systemschnittstellen: BSD-Sockets, Transport Level Interface (TLI),
System-V-Streams [Riek92].
• Graphik: Windows, OSF/Motif, zum Teil auch IRIS GL bzw. OpenGL. Die GraphikNormen CGI [ISO/IEC 9636], GKS [ISO 7942], GKS-3D [ISO/IEC 8805] und PHIGS
[ISO/IEC 9592] haben sich in der Praxis nicht durchgesetzt.
3.2 Beispielanwendung
3.2.1 Anforderungen
Die Benutzeroberfläche derzeit verfügbarer Client/Server-Systeme sowie dort integrierter
Viewer unterstützt das „Buch-Paradigma“ nicht zufriedenstellend. Eine gute allgemeine
Akzeptanz des Online-Dienstes kann beim Anwender nur durch hohen Komfort erzielt werden. Dies kann erreicht werden, wenn die Bedienoberfläche dem Vorgang des Lesens in
einem Buch angepaßt wird. Dazu gehört sowohl die Art und Weise des Zugriffs, also die
graphische Gestaltung und Logik der Bedienung, als auch die genügend schnelle Reaktion
(Quality of Service).
Zur Diskussion des (Echt-)Zeitverhaltens von interaktiven Multimedia-Systemen sei auf
[Adi93, Kröm92, Shnei84, Stae93, Will94] verwiesen. Die dort angegebenen maximalen
Reaktionszeiten lassen sich auch durch Vergleich mit dem herkömmlichen Buch-Medium
unter verschiedenen Randbedingungen ableiten:
•
•
„Blättern“ (Erzielung erster Eindrücke, Gewinnung eines Überblicks):
Bildqualität:
Bitmap-Darstellung ausreichend, d. h. 1 bit/pixel.
Reaktionszeit:
ca. max. 0,2 s.
„Lesen einer Seite“ (Genauere Betrachtung, längere Verweilzeit, Forderung nach hoher Detail-Auflösung und guter Lesbarkeit):
Bildqualität:
Echtfarb-Darstellung erforderlich, d. h. 24 bit/pixel.
Reaktionszeit:
ca. max. 2 s.
Mit heutiger Bildschirm-Technologie kann z. B. eine Seite im DIN-A4-Format mit einer
Auflösung von 100 dpi vollständig dargestellt werden; dies entspricht einer Pixelanzahl von
826 x 1169 = 965594. Unter der Annahme, daß die Hälfte der verfügbaren Verzögerungszeit für den Datentransport genutzt werden kann, müssen (Netto-)Burstraten gemäß folgender Tabelle erzielt werden.
Tabelle 4: Anforderungen für das Szenario „Blättern“
Medientyp
Farbtiefe
Volumen
Max. Delay
Min. Burstrate = 2/Delay
Bilevel-Image
1 bit
120 KByte
0,2 s
9,7 Mbps
True-Color-Image
24 bit
2,8 MByte
2s
23 Mbps
3.2.2 Standard-Client/Server-System: World Wide Web
Das im Internet verbreitete verteilte Online-Informationssystem, World Wide Web
(WWW), setzt i. w. auf dem TCP/IP-basierten HTTP-Protokoll (Hypertext Transfer Protocol) [Bern93a] auf. Das Klientensystem (z. B. Mosaic oder netscape) fordert zunächst
über eine sog. URL (Uniform Resource Locator) [Bern93c] vom Serversystem (z. B.
httpd) ein Dokument an. Das daraufhin übermittelte Dokument wird dann, je nach Dokumententyp, entweder direkt angezeigt (z. B. HTML – Hypertext Markup Language
[Bern93b], einer SGML[ISO/IEC8879]-konformen Sprache) oder über eine temporäre
Datei von einem medientypspezifischen Viewer präsentiert (z. B. xv für Rasterbilder). Der
Kontroll- bzw. Datenfluß – speziell für die Online-Präsentation von Rasterbildern im TIFFFormat – ist in Abb. 2 dargestellt.
Server
Client
Tastatur,
Maus
TIFF
file
read
1
Display
TCP/IP/
HTTP
0
TIFF
(file decoder)
7
file
write
read
X11
xv
X Server
httpd
Mosaic
2
3
4
6
(complete file)
5
Abb. 2: Prozeß- und Datenfluß-Diagramm für WWW (World Wide Web)
Prinzipiell können anhand der Datenflüsse und Prozesse in Abb. 2 die folgenden potentiellen Engpässe – verursacht durch Latenz-, Transfer- und Rechenzeiten – identifiziert werden
(in Klammern sind die jeweiligen Einflußgrößen aufgeführt):
0. Verzögerungszeiten bei Verbindungsaufbau und Dokument-Anforderung.
1. Latenz- und Transfer-Zeiten beim Lesen eines Rasterbildes im TIFF-Format von Datei (max. interne
Transferrate auf Magnetplattenspeicher, Kanalkapazität, Dateisystem).
2. Transport-Zeit über das Netz (Netzprotokolle, Netzinfrastruktur, Transferrate).
3. Latenz- und Transfer-Zeiten beim Schreiben auf Datei (siehe 1).
4. Latenz- und Transfer-Zeiten beim Lesen von Datei (siehe 1).
5. Konvertierungszeit (TIFF- in X-Window-Rasterbild-Repräsentation: Dateidecodierung, ggf. FarbmodellUmrechnung oder/und Farbreduktion, z. B. 24 bit/Pixel TrueColor in 8 bit/Pixel PseudoColor, DitheringVerfahren).
6. Tranport-Zeit über das X-Window-Protokoll (TCP/IP- oder UNIX-Domain-Socket-Kommunikation,
Nutzung der Shared-Memory-Extension des X-Window-Systems).
7. Zeiten für Konvertierung und Transport eines X-Images in den jeweiligen Framebuffer (X-Server-Implementierung, Kanalkopplung – z. B. S-Bus, Graphikhardware).
Für die aufgrund der hohen Datenmengen kritischen Pfade wurden auf verschiedenen Plattformen Leistungsmessungen durchgeführt (siehe Tabelle 5).
Tabelle 5: Leistungsmessungen der kritischen Pfade auf verschiedenen Plattformen
(Angaben: jeweils Maxima in MByte/s, wobei 1 MByte = 220 Byte)
Sun
IBM
HP
SGI
SGI
SS 10/30,
CG6,
SunOS
4.1.3
RS/6000320,
AIX
9000/715,
HP/UX
9.0.5
Indigo2
Extreme,
IRIX 5.2
Onyx
Reality
Datei-Lesevorgang(100 x 1 MByte)
3,2
1,8
2,1
7,8
6,2
TCP/IP-Loopback-Transfer (100 x 1 MByte)
3,0
1,9
10,0
19,2
17,8
XPutImage
2,7
1,9
13,8
5,9
7,5
XCopyArea
9,8
6,8
44,8
19,2
29,8
memcpy (CG6)
9,9
–
–
–
–
–
–
–
24,2
31,4
–
–
–
–
71,4
–
–
–
37,8
102,2
Messung
Display
(100 x
1000x800
Pixel
8 bit/Pixel
lrectwrite
24 bit/Pixel
32 bit/Pixel
lrectwrite
Engine2,
IRIX 5.2
3.2.3 Entwicklung eines eigenen Client/Server-Systems: DocShow/DocServ
Wegen der in den üblichen WWW-Systemen vorhandenen Ineffizienzen bzw. Overheads
wurde ein eigenes Client/Server-System entwickelt, welches durch eine besonders effiziente
Implementierung sowie neuartige Konzepte einige Vorteile aufweist. Darüber hinaus wurde
ein Meß-Interface integriert, um Benchmarks zu ermöglichen. In Abb. 3 ist die realisierte
Konfiguration dieses DocShow/DocServ-Systems dargestellt.
Server
Client
Tastatur,
Maus
TIFF
file
2
(strips)
GL
6‘‘
DocShow
DocServ
1
IRIS
TCP/IP
0
read
Display
7
X11
X Server
6‘
5‘
Abb. 3: Prozeß- und Datenfluß-Diagramm für DocShow/DocServ
Zu den bisher realisierten leistungssteigernden Maßnahmen gehören:
• Entwurf eines eigenen verbindungsorientierten, statusbehafteten Protokolls. Ein zeitaufwendiger Verbindungsaufbau – dieser wird zukünftig auch Authentifizierungs- und
Abrechnungsaufgaben erfüllen müssen – ist nur einmal erforderlich; Prefetching erfordert keine weitere simultane Verbindung; für das schnelle „Blättern“ kann ein PlayOut-Szenario – analog zu Video-on-Demand-Anwendungen – angesetzt werden; darüber hinaus bietet die serverseitige Status-Speicherung auch strukturelle Vorteile.
• Vermeidung von Speichervorgängen auf Datei auf Clientseite: ein Lese- und Schreibvorgang auf Datei je Seite entfällt (Pfade 3 und 4 in Abb. 2).
• Sequentialisierung des direktzugriffsorientierten TIFF-Formats (Definition eines striporientierten Datenstromprotokolls). Dies ist zur Ermöglichung eines sukzessiven Bildaufbaus erforderlich und um die Perspektive zu bieten, die in einer Pipeline
angeordneten Prozesse Transfer, Convert und Display zeitlich überlappt ausführen zu
können (Multi-Threading, Multi-Processing). Zur Decodierung des TIFF-Formats
wurde Sam Lefflers TIFF-Library (ftp://sgi.com/pub/graphics) verwendet und an einigen Stellen erweitert.
• Verwendung von bildtypabhängigen „Visuals“ für die anzuzeigenden X-/GL-Images
(Bitmaps für Bilevel-Bilder, Pixmaps für Farbbilder): dadurch werden Display-bezogene Konvertierungs- und Datenvolumen-Aufwände reduziert.
• Effiziente Implementierung des Dithering-Verfahrens in (5‘). Die wegen der oftmals
eingesetzen 8-Bit-Graphik-Hardware ggf. notwendige Farbreduktion von der 24-BitTrue-Color- in eine 8-Bit-Pseudo-Color-Darstellung wurde mittels 4x4-Ordered-Dither-Matrix [Foley90] über ein neu entwickeltes Table-Lookup-Verfahren realisiert. Ein
Leistungsvergleich mit den Internet-Werkzeugen xv und display (ImageMagick)
zeigte an dieser Stelle einen besonderen Bedarf zur Optimierung [Pra94].
• Hardware-nahe Display-Ansteuerung, soweit dies portabel möglich ist. Unterstützt
werden die APIs Xlib (optional: Shared-Memory-Extension, 6‘) und IRIS GL (6‘‘).
• Sukzessiver Bildaufbau durch blockweise, timer-gesteuerte Display-Ausgabe. Dies ist
erforderlich wegen der u. U. signifikanten Startup-Zeit einer einzelnen Display-Ausgabe (z. B. ist die Ausgabe in Form von einzelnen Scanlines erheblich langsamer als
die Ausgabe eines vollständigen Rechtecks).
• Cache-Pufferung mit LRU(Least Recently Used)-Strategie.
Für die zu Validierungszwecken durchgeführten Messungen wurden unkomprimierte Bilevel- bzw. TrueColor-Bilder mit einer Auflösung von 826x1169 Pixel im TIFF-Format verwendet, wobei jeweils der gesamte Bildinhalt in einem einzigen TIFF-Strip abgelegt war.
Die Kommunikation zwischen DocServ und DocShow erfolgte über eine TCP/IP-Loopback-Verbindung. Es wurden die Unterschiede in bezug auf Systemverhalten und Durchsatz
beim Einsatz jeweils zweier verschiedener Verfahren zum
• Lesen von Datei:
(a) gewöhnlicher Datei-Lesezugriff (UNIX-System-Call: read),
(b) Memory-Mapped-I/O (UNIX-System-Call: mmap,
anschließend Lesen über virtuellen Speicher); und
• Rasterbild-Display:(d) X-Windows (Xlib-Call: XPutImage,
optional DISPLAY=shm:0 für Shared-Memory-Extension),
(e) IRIS GL (IRIS-GL-Call: lrectwrite)
ausgewiesen.
Die in Tabelle 6 dargestellten Meßergebnisse wurden auf einer Silicon Graphics Onyx Reality Engine2 (4 x R4400, 150 MHz, 2 Raster-Manager, Betriebssystem: IRIX 5.2) ermittelt.
Tabelle 6: Leistungsmessungen in DocShow/DocServ (Version 1.26)
(Angaben: jeweils maximale Durchsatzraten; 1 Mbps = 106 bit/s)
Startup(+Read)
Image/
Display
Depth
Transfer
mit TIFF-read (a)
mit TIFF-mmap (b)
bit/Pixel
ms
Mbps
ms
Mbps
38
25,4
134
7,2
1/1
39
–
124
7,8
24/8 (LUT,
Dithering)
514
45,1
222
104,4
70
–
621
37,3
24/24
(RGB)
514
45,1
222
104,4
70
–
621
37,3
24/32
(ABGR)
514
45,1
222
104,4
Decode+
Convert (c)
(Dithering, etc.)
Mbps: bezogen
auf Quelldaten
ms
Mbps
9
107
314
242
241
70
–
621
Display
Summen
XPutImage (d)
(DISPLAY=:0/
shm:0)
a+c+d
a+c+e
lrectwrite (e)
b+c+d
b+c+e
ms
Mbps
ms
ms
28/13
34/74
194
285
104 *
9,3
185
276
195/115
40/67
1165
–
–
–
1120
–
–
–
–
1019
41
567
–
974
481/115
64/269
1092
1015
38
813
1047
970
73,8
95,7
96,2
37,3
*) Hier besteht noch Unklarheit über das Vorliegen eines System- oder Implementierungsproblems.
Weiterhin untersucht werden die Auswirkungen
• verschiedener Maschinen-Architekturen (HP, IBM, SGI, Sun);
• verlustloser und verlustbehafteter Kompressionsverfahren:
– G3- und G4-FAX-Codierung für Bilevel-Bilder,
– LZW- und JPEG-Codierung für Echtfarbbilder;
• der Block- bzw. Strip-Längen;
• unterschiedlicher Netz-Infrastruktur (Ethernet, Ultranet, ATM).
Eine ausführliche Darstellung findet sich in [Olb95].
4 Literaturverzeichnis
[Adie93]
[Bern93a]
[Bern93b]
Adie, C.: „Network Access to Multimedia Information“. 09.08.1993 (RARE
Technical Report). URL=ftp://ftp.ed.ac.uk/pub/mmacess.
Berners-Lee, T., Connolly, D.: „Hypertext Markup Language – A Representation of Textual Information and Metainformation for Retrieval and Interchange“. Internet Draft, 1993.
Berners-Lee, T.: „Hypertext Transfer Protocol – A Stateless Search, Retrieve
and Manipulation Protocol“. Internet Draft, 1993.
[Bern93c]
Berners-Lee, T.: „Uniform Resource Locators – A unifying syntax for the
expression of names and addresses of objects on the network“. Internet Draft,
1993.
[Comp94]
Computerwoche: „Nur Bildschirme für 200000 Dollar eignen sich zum
Lesen“. In: Computerwoche 22, 3. Juni 1994.
DFN: „Graphik und Netzdienste in wissenschaftlichen Anwendungen“. DFNBericht Nr. 67, September 1992.
Foley, J. D. et al.: „Computer Graphics – Principle and Practice“. 2nd ed.,
Addison-Wesley, Reading, 1990.
[DFN92]
[Foley90]
[ISO7942] ISO 7942: „Graphical Kernel System (GKS)“. 1985.
[ISO/IEC8805]ISO/IEC 8805: „Graphical Kernel System for Three Dimensions (GKS3D)“. 1988.
[ISO/IEC8879]ISO/IEC 8879: „Standard Generalized Markup Language (SGML)“. 1979.
[ISO/IEC9592]ISO/IEC 9592: „Programmers Hierarchical Interactive Graphics System
(PHIGS)“. 1989.
[ISO/IEC9636]ISO/IEC 9636: „Interfacing Techniques for Dialogues with Graphical
Devices (Computer Graphics Interface, CGI)“. 1991.
[Kröm92] Krömker, D.: „Visualisierungssysteme“. Springer-Verlag, 1992.
[Kröm94a] Krömker, D.: „High-Definition Multimedia-Systeme im Office 2000“.
CG topics 1/94.
[Lie92]
Lie, H., Bender, W.: „The Electronic Broadsheet: all the News that fit the Display“. In: EP 92, Proceedings of Electronics Publishing, 1992.
[Olb95]
[Pra94]
[Riek92]
[Shnei84]
[Stae93]
[Stein93]
[Will94]
Olbrich, S., Pralle, H., Grüneberg, L.: „Technische Aspekte des Online-Publishing“ (in Vorbereitung)
Pralle, H. et al: „Online-Dokumente“, RTB-Nord/P5-Feinspezifikation,
Version 3.3. RRZN/RVS Universität Hannover, Juli 1994.
Rieken, B., Weiman, L.: „Adventures in UNIX Network Programming“.
Wiley & Sons, 1992.
Shneiderman, B.: „Response Time and Display Rate in Human Performance
with Computers“. ACM Computing Surveys 16,3 (1984).
Staehli, R., Walpole, J.: „Constraint-Latency Storage Access“. IEEE Computer, March 1993, Vol. 26, Nr. 3, 44-53.
Steinmetz, R.: „Multimedia-Technologie“. Springer-Verlag, 1993.
Williams, N., Blair, G. S.: „Distributed multimedia applications: A review“.
Computer Communications 17,2 (1994).