Ein wichtiger Parameter, der für die Entscheidung, welches komprimierte Audioformat noch über die Netzverbindung übertragen werden kann, sehr wichtig ist, ist die zur Verfügung stehende effektive Nutzbandbreite. Es gibt dabei zwei Ansätze, diesen Parameter zu erhalten:
Jede der beiden Varianten hat seine Vor- und Nachteile. Der erste Ansatz erfordert einen gewissen Aufwand für die Konfiguration. Wird beispielsweise ein Router benutzt wird, der dynamisch neue ISDN B-Kanäle auf- oder abbaut (je nach momentaner Auslastung), ist dies nicht so einfach zu benutzen. Die PPP-Protokolle müßte hierzu schon direkt die Information erhalten, wieviele Kanäle derzeit zur Verfügung stehen. Das Verfahren versagt aber dann, wenn es sich um ein Medium handelt, bei dem die Bandbreite von vornherein nicht feststeht, oder schwanken kann, wie etwa bei Modem-Verbindungen.
Die zweite Variante birgt die Gefahr der Fehlmessung, etwa bei Datenkompression. Weiterhin wäre es zu erwarten, daß ein zusätzlicher Aufwand nötig ist, um während einer laufenden Verbindung die Bandbreite messen zu können. Auf der anderen Seite können so dynamische Änderungen, wie die Anpassung der Anzahl der B-Kanäle oder die Verwendung eines anderen Übertragungsverfahren bei einer Modem Verbindung, erkannt werden.
In diesem Kapitel befassen wir uns mit dem zweiten Ansatz, der Messung der effektiv zur Verfügung stehenden Bandbreite einer PPP-Verbindung über eine Modemstrecke. Wir betrachten dabei die Einstellungen verschiedener Parameter, und versuchen jeweils eine Beziehung zwischen der gemessenen und tatsächlich vorhandenen Bandbreite herzustellen.
Für die Messung der Bandbreite verwenden wir ein Verfahren, das sich "Packet-Pair" nennt [Kesh94:Packet]. Es wird hierbei die Verzögerung gemessen, in der zwei direkt hintereinander gesendete Datenpakete beim Empfänger eintreffen. Diese spezielle Idee wurde von uns aus einer Arbeit abgeleitet, die sich mit der Bestimmung von Bottlenecks zwischen zwei entfernten Stationen befaßte [Chen97:Bottleneck].
Wir beschreiben das Verfahren hier nicht weiter, und verweisen stattdessen auf die beiden Arbeiten [Kesh94:Packet][Chen97:Bottleneck].
Die Messungen wurden unter Verwendung des in [Chen97:Bottleneck] beschriebenen "Packet-Pair-Verfahrens" durchgeführt. Gemessen wurde demzufolge die Zeit, die für den Empfang des zweiten Paketes benötigt wurde. Die Versuche wurden im 1-Sekunden Rhythmus 100 mal ausgeführt, und jeweils die effektive Bandbreite errechnet.
Sofern nicht anders beschrieben, wurden alle anderen Protokolle ausgeschaltet, es wird also ohne Datenkompression und Fehlerkorrektur gearbeitet:
Auch für die PPP-Verbindung wurden alle Arten von Kompression ausgeschaltet:
Die Geschwindigkeit zwischen dem Modem und dem jeweiligen Rechner betrug 38400 bit/s. Somit ist sichergestellt, daß diese Schnittstelle kein Engpaß darstellt.
Weiterhin wurde die Asynchron Control Character Map (ACCM) [rfc1662] auf den Wert 0x00000000 gesetzt, so daß keine Byte-Werte escaped werden müssen. Um eventuelle Optimierungen oder Kompressionen im Datenstrom weitgehend ausschließen zu können, wurde der Datenpuffer der zu übertragenen Pakete immer mit zufälligen Werten gefüllt
Das Programm auf der Empfängerseite empfängt die beiden Pakete und mißt die Zeit, die zwischen dem Eintreffen des ersten und zweiten Paketes vergeht. Mit Hilfe der Größe des empfangenen zweiten Paketes und der gemessenen Zeit, wird die resultierende effektive Bandbreite errechnet und ausgegeben. Ein Ausschnitt aus einem solchen Protokoll zeigt die folgende Liste:
Die erste Spalte gibt die Testnummer an, die zweite die errechnete effektive Bandbreite in kbit/s. Die dritte dient nur zur Kontrolle und enthält die gemessene Zeit in Millisekunden.
... 10 3.200051 # 249.996 ms 11 3.077278 # 259.970 ms 12 3.200013 # 249.999 ms 13 3.200166 # 249.987 ms 14 3.199987 # 250.001 ms 15 3.199962 # 250.003 ms 16 3.077290 # 259.969 ms 17 3.200102 # 249.992 ms 18 3.200166 # 249.987 ms 19 3.200038 # 249.997 ms 20 3.200013 # 249.999 ms ...
Ein Byte besteht aus 8 Bits, demzufolge müßten
B | = | (4800 / 8 ) |
| = | 600 |
übertragen werden können. Aufgrund des Start- Stopbit Verfahren werden jedoch 10 Datenbits für 8 Nutzdaten-Bits übertragen. Die somit für Nutzdaten effektiv zur Verfügung stehende Bandbreite Beff ergibt somit zu
B | = | (4800 / 10 ) |
| = | 480 | |
| = | 480 * 8 / | |
| = | 3840 / |
Bei einer Bandbreitenmessung müßte somit einen Wert ergeben, der dem in der Gleichung [bandbr-Beff] entspricht.
Es ergibt sich somit ein Overhead O von
O | = | B - B |
| = | 4800 - 3840 | |
| = | 960 | |
| O | = | O / B |
| = | 960 / 3840 | |
| = | 25% |
, es werden also 25% mehr Bits übertragen, als an Nutzdaten anfallen.
Erläuterung der einzelnen Ebenen:
Die Verwendung des Flags kann je nach Implementierung ein wenig variieren. Werden zwei PPP-Pakete direkt hintereinander gesendet, Können die beiden Flags zwischen den beiden Paketen (am Ende des ersten und am Anfang des zweiten) durch eins ersetzt werden. Obwohl die von uns verwendete PPP-Implementierung[ Wir verwendeten die Implementierung PPP-2.2, die als Sourcecode der Linux 2.0 Distribution beiliegt.] dies unterstützt, wurden jedoch immer beide Flags gesendet.
Bei der Verwendung von PPP kann es vorkommen, daß einige Bytewerte "escaped" werden müssen (siehe [ppp-accm]). Auch wenn die ACCM auf 0x00000000 eingestellt wurde, werden weiterhin Bytewerte, die dem Wert eines FLAG und eines ESC entsprechen, escaped. Somit entsteht ein weiterer Overhead, so daß sich die Anzahl der zu versendenden Bytes Nesc(n) um die Auftrittswahrscheinlichkeit der beiden Werte erhöht.
N(n) | = | n + n * (2 / 256) |
| = | n * (1 + 2 / 256) | |
| = | 1,007812 * n |
Die reale Größe in Bytes eines zu übertragenden Datenpaketes über UDP ist somit erheblich größer:
| = | N + N (N + N + N + N + n) | |
| = | 2 + 1,007812 * (8 + 20 + 2 + 4 + n) | |
| = | 2 + 1,007812 * (34 + n) | |
, die Summe aus den Overheads der einzelnen Protokollebenen und den eigentlichen Nutzdaten (n), erhöht um den Overhead für das eventuelle Escapen, zuzüglich der das Frame einschließenden Flags.
Aufgrund der Übertragung der Daten nach V.14 (Start-Stopbit), ergibt sich somit ein Bitstrom mit folgender Größe:
N(n) | = | N(n) * 10 |
| = | (2 + 1,007812 * (34 + n)) * 10 | |
| = | 20 + 10,07812 * (34 + n) |
Die effektive Nutzdatenbandbreite B(n) für UDP-Pakete mit n Bytes Nutzdaten, ergibt sich aus der Differenz der realen Bandbreite B und der durch den Overhead verschwendeten Bandbreite B(n):
B(n) | = | B - B(n) |
Die Bandbreite B(n), die durch den Overhead belegt wird ergibt sich aus dem Produkt der realen Bandbreite B und dem relativen Overhead O(n):
B(n) | = | B * O(n) |
Der relative Overhead O(n) ergibt sich aus dem Overhead O(n) in Bits und den tatsächlich übertragenen Bits N(n):
O(n) | = | O(n) / N(n) |
Der Overhead in Bits O(n) ergibt sich aus den tatsächlich übertragenen Bits N(n) und der Anzahl der Bits der Nutzdaten (8 * n):
O(n) | = | N(n) - 8 * n |
Durch Einsetzen der Teilformeln ergibt sich folgende Gleichung für B(n):
B(n) | = | B - (B * ((N(n) - 8 * n) / N(n))) |
|
| = | B - (B * (((20 + 10,07812 * (34 + n)) - 8 * n) / (20 + 10,07812 * (34 + n)))) |
Mit Hilfe dieser Gleichung können wir nun die zu erwartenden Bandbreite in Abhängigkeit von der Nutzdatengröße errechnen. Die sich ergebenen Werte sind in der Abbildung [ppp-bandw-est] graphisch dargestellt.
Es ist deutlich zu erkennen, daß die effektive Bandbreite mit zunehmender Paketgröße steigt, und daß ihr Maximum bei etwas über 3,5 kbit/s liegt. Die ebenfalls deutlich sichtbaren diskreten Stufen sind auf den Escape-Mechanismus zurückzuführen.
Um eine genauere Aussage über die Qualität unserer theoretischen effektiven Bandbreite machen zu können, wurden die Messungen jeweils arithmetisch gemittelt, und der sich ergebende Graph mit dem aus der theoretischen Betrachtung zusammen dargestellt (siehe Abbildung [ppp-bandw-est-exp]).
Es ist eine deutliche Übereinstimmung der beiden Kurven zu erkennen, so daß davon auszugehen ist, daß unsere Überlegungen richtig waren. Um eine noch genauere Aussage treffen zu können, stellten wir die prozentualen Abweichung zwischen den gemessenen und berechneten Werten in der Abbildung [ppp-bandw-est-exp-error] dar.
Es zeigt sich, daß die Abweichung unterhalb von 1% liegt, wenn die Pakete mehr als ca. 10 Byte Nutzdaten fassen. Aber auch unterhalb dieser Größe liegt sie bei weniger als 1,5%. Das die Schwankungen mit zunehmender Datengröße in den Paketen abnimmt, läßt sich durch den Escape-Mechanismus erklären. Bei kleinen Paketen macht sich ein mehr zu escapendes Byte stärker bemerkbar, als bei größeren.
Es kann somit davon ausgegangen werden, daß die angegebene Formel eine sehr gute Annäherung an die tatsächliche Bandbreite darstellt.
Jede der beiden Stationen hat eine sogenannte "Asynchron Control Character Map" (ACCM [rfc1662]), die angibt, welche der unteren 32 Control-Character über diesen Mechanismus escaped werden müssen. Beim Aufbau einer PPP-Verbindung ist zum Anfang diese Map auf den Wert 0xFFFFFFFF eingestellt, jeder der 32 Control-Character von 0x00 bis 0x1F muß escaped werden. Diese ACCM kann jedoch mittels des "Link Control Protocol" (LCP) [rfc1661] geändert werden und wird in den meisten Fällen auf 0x000A0000 (nur XON, XOFF, ESC und FLAG escapen) oder sogar auf 0x00000000 (nur ESC und FLAG escapen) eingestellt.
Diese Einstellung hat einen Einfluß auf die Messung der Bandbreite, da somit eine variable Anzahl von Bytes zum eigentlichen Frame hinzukommen (ein ESC für jedes zu escapende Zeichen). Um die Auswirkung der ACCM für die Bandbreitenmessung bewerten zu können, leiten wir uns wiederum die zu erwartende effektive Bandbreite mathematisch her, und werden diese anhand realer Messungen verifizieren.
In [ppp-bandw-theor] haben wir bereits erwähnt, daß zwei Bytewerte in jedem Fall escaped werden müssen, unabhängig von der jeweiligen ACCM. Wir definierten die insgesamt durch das escapen zu übertragenden Bytes N wie folgt:
N(n) | = | n * (1 + 2 / 256) |
N(n) gab die zu übertragenen Bytes für eine ACCM von 0x00000000 an, so daß nur die beiden Werte ESC und FLAG escaped werden müssen. Im allgemeinen läßt sich N(n) bei einer gegebenen ACCM wie folgt definieren:
| = | n * (1 + e / 256) |
, wobei e die Anzahl der zu escapenden Bytewerte angibt. Der Wert ergibt sich aus der Anzahl der gesetzten Bits in der ACCM plus 2:
e | = | _ (ACCM) + 2 |
Zuvor haben wir bereits die Anzahl der zu übertragenden Bytes durch die Gleichung [ppp-bandw-N] beschrieben. Setzen wir dort unsere neue Funktion für N ein, so ergibt sich folgendes:
N(n,e) | = | O + N (O + O + O + O + n,e) |
| = | 2 + (1 + e / 256) * (8 + 20 + 2 + 4 + n) | |
| = | 2 + (1 + e / 256) * (34 + n) |
Setzen wir diese in die Gleichung zur Berechnung der effektiven Bandbreite [ppp-bandw-beff] ein, so erhalten wir folgende Gleichung für die effektive Bandbreite in Abhängigkeit von der Anzahl der gesetzten Bits e in der ACCM:
| = | B - (B * ((N(n) - 8 * n) / N(n))) | |
| = | B - (B * ((10 * (2 + (1 + e / 256) * (34 + n)) - 8 * n) / (10 * (2 + (1 + e / 256) * (34 + n)))) | |
| = | B - (B * ((20 + (10 + e / 25,6) * (34 + n) - 8 * n) / (20 + (10 + e / 25,6) * (34 + n)))) |
Die graphische Darstellung ist in Abbildung [ppp-bandw-est-accm] zu sehen
Es ist deutlich zu erkennen, daß die ACCM einen großen Einfluß auf die gemessene Bandbreite hat. Sie schwankt um ca. 0.5 kbit/s je nach Einstellung der ACCM.
Heutzutage arbeiten nahezu alle Modems mit Fehlerkorrektur, wobei meistens V.42 [itu9303:V.42] verwendet wird. Dies hat nun wiederum einen erheblichen Einfluß auf die zur Verfügung stehenden Bandbreite. Die auf dem ersten Blick widersprüchlich erscheinende Aussage ist, daß sich der Durchsatz erhöht, trotz zusätzlichem Overhead durch V.42.
Der Grund für die Zunahme der Bandbreite ist darin begründet, daß bei V.42 keine Bytes, sondern HDLC Frames (es sind hierbei nicht die PPP-HDLC-Frames gemeint!) übertragen werden (genauer LAP-M). Somit entfallen die sonst nötigen Start- und Stopbits pro Byte, die immerhin einen Overhead von 25% ausmachen (10 Bits im Gegensatz zu 8). Anstelle eines Bytestroms, der übertragen wird, haben wir es nun mit einem bit-seriellen Datenstrom zu tun. Um Frame-Grenzen etc. erkennen zu können, müssen besondere Kodierungsverfahren verwendet werden.
Um die reinen Daten von Framing-Informationen unterscheiden zu können, wird bit-stuffing benutzt. Hierbei wird nach einer Folge von fünf aufeinanderfolgender 1-Bits im Datenstrom ein 0-Bit eingestreut. Der Empfänger entfernt auf seiner Seite dies Bit wieder, und erhält somit den reinen Datenstrom. Tritt dabei eine Verletzung des Verfahrens auf (es wurden mehr als fünf hintereinanderfolgende 1-Bits empfangen), so handelt es sich hierbei um Framing-Informationen.
Wie bei HDLC üblich kommen nun wiederum Octets zum Datenstrom dazu, wie Flag, Address, Control etc. Dennoch erhöht sich der Datendurchsatz durch den Wegfall von Start- und Stopbit und dem Einstreuen von Bits durch bit-stuffing erheblich.
Betrachten wir diesen Fall zunächst aus theoretischer Sicht. Der Nutzdatenstrom besteht aus einer Folge von Bytes, zu je acht Bits. Um unsere effektive Bandbreite zu bestimmen, müssen wir den Datenstrom (inklusive Paket-Overhead) als einen reinen Bitstrom betrachten. Die Wahrscheinlichkeit, daß in einem Datenstrom Folgen von fünf 1-Bits austreten ist gegeben durch die folgende arithmetische Reihe:
p | = | 1 * .57 (p ('0-11111-0')) |
| = | + 1 * .58 (p ('0-11111-10')) | |
| = | + 1 * .59 (p ('0-11111-110')) | |
| = | + 1 * .510 (p ('0-11111-1110')) | |
| = | + 1 * .511 (p ('0-11111-11110')) | |
| = | + 2 * .512 (p ('0-11111-11111-0')) | |
| = | + 2 * .513 | |
| ... | ||
| = | + 3 * .517 (p ('0-11111-11111-11111-0')) | |
| ... | ||
Mit Hilfe von Rainer Baier (er antwortete auf diese Frage in der Fokus Mailing List) konnte diese Reihe in die Summenformel
p | = | 31 / 64 * SUMi=1n (i / (32i)) |
transformiert werden. Mit Hilfe des folgenden kleinen bc Programms
scale=99 x=0 for (i=1; i<100; i++) x += i / (32 ^ i)
31 / 64 * x
wurde der angenährte Wert ermittelt:
p | = | .016129... |
Der Overhead beträgt somit nur 1,6129%, deutlich weniger als bei Verwendung von Start- und Stopbits (mit 25%). n1 = (1 + p) = 1,016129 stellt zugleich den Faktor dar, um den sich der Datenstrom (mit Ausnahme der FLAGS) vergrößert.
Zu den zu übertragenden Nutzdaten kommt nun noch der relativ statische Overhead durch das HDLC ähnliche Framing beim LAP-M (vgl. auch [ppp-ip-udp-frame]). Dies sind
Es kommen also noch 7 Bytes Overhead dazu, wobei in den Flags kein bit-stuffing ausgeführt wird. Die statistisch durchschnittliche Größe der zu übertragenden Daten N(n) bei Paketen mit n Bytes PPP-Daten ergibt sich zu
N(n) | = | (n + 5) * 1,016129 + 2 |
Setzen wir dies in unsere Gleichung [ppp-bandw-N] ein, so ergibt sich folgende Gleichung:
N(n,e) | = | 2 + n1 * (5 + O + N (O + O + O + O + n,e)) |
| = | 2 + n1 * (5 + 2 + (1 + e / 256) * (8 + 20 + 2 + 4 + n)) | |
| = | 2 + n1 * (7 + (1 + e / 256) * (34 + n)) |
Diese wiederum verwendet in [ppp-bandw-Beff-n-e-1], unter der Berücksichtigung, daß nun kein Start- Stopbit-Verfahren mehr verwendet wird, ergibt folgende Gleichung für die Berechnung der zu erwartenden effektiven Bandbreite:
B(n,e) | = | B - (B * ((N(n) - 8 * n) / N(n))) |
| = | B - (B * ((8*(2 + n1 * (7 + (1 + e / 256) * (34 + n))) - 8 * n) / (8 * (2 + n1 * (7 + (1 + e / 256) * (34 + n)))) | |
Wiederum führten wir einige Messungen mit verscheiden großen UDP Paketen durch. Die Ergebnisse sind in der Abbildung [ppp-bandw-v42] graphisch dargestellt. Ebenfalls wurde die zu erwartende effektive Bandbreite mit dargestellt.
Es ist sehr deutlich zu erkennen, daß die theoretisch zu erwartende effektive Bandbreite von der gemessenen mit zunehmender Paketgröße, stärker abweicht, sie ermittelt einen Wert, der stets größer ist. Der vermutliche Grund hierfür könnte die Beschränkung der maximalen verwendeten Frame-Größe des LAB-M sein (der Parameter N401 nach V.42). Aus diesem Grunde haben wir noch zwei weitere Funktionen für die zu erwartenden effektiven Bandbreite dargestellt, die eine berücksichtigt eine Wert von 128, die andere einen von 256 Octets für den Parameter N401.
Anhand der Graphiken könnte man darauf schließen, daß die verwendete Frame-Größe zwischen den beiden Modem ca. 128 Octets betragen dürfte. Leider gibt es für uns als Benutzer eines Modem keine Möglichkeit, die zwischen den beiden Modems ausgehandelten Werte für diesen Parameter zu erfragen. Auch die ITU [itu9303:V.42] Norm gibt uns hierfür keinerlei Hinweise, daß einzige was erwähnt wird ist, daß jede Implementierung eine Frame-Größe von 64 Bytes unterstützen sollte. Die oben gegebene Erklärung für die Abweichungen bleiben also nur eine reine, wenn auch unserer Meinung nach sinnvolle Vermutung unsererseits, die wir jedoch nicht genau belegen können!
PPP-Verbindungen werden, wie der Name bereits andeutet, als Protokoll zwischen zwischen exakt zwei Endpunkten benutzt. Aus diesem Grunde ist es eigentlich auch unnötig, das HDLC-Address-Feld (vgl. [ppp-ip-udp-frame]), daß immer eine Broadcast Adresse (0xFF) enthält, zu übertragen. Aus diesem Grunde kann mittels LCP Nachrichten vereinbart werden, daß dieses Feld entfallen kann.
Wie dem auch sei, je nach gewählten Optionen können somit maximal zwei Bytes im Datenstrom eingespart werden, so daß die zu erwartende effektive Bandbreite nur um zwei Bytes nach links verschoben sein dürfte (sie müßte nun bei einer Nutzdatengröße von n+2 so groß sein, wie zuvor bei einer Größe von n. Aufgrund der Einfachheit der Kompression verzichten wir an dieser Stelle aus entsprechende Messungen und Berechnungen der zu erwartenden effektiven Bandbreite.
Die große Frage ist, in wie weit sich diese Datenkompression auf die Bandbreite auswirkt. Unser Ziel war es, anhand von Messungen während einer bestehenden Modemverbindung die Bandbreite bestimmen zu können, und mit Hilfe von abgeleiteten Formeln die für uns nutzbare effektive Bandbreite bestimmen zu können.
Wiederum führten wir einige Messungen über eine aufgebaute PPP-Verbindung durch. Bei der Betrachtung der Ergebnisse viel auf, daß sehr starke Schwankungen bei Messungen mit gleichen Paketgrößen auftraten. Bei einer Nutzdatengröße von 100 Bytes geb es sogar regelmäßige Peaks von über 25 kbit/s, obwohl der zu übertragene Datenstrom zufällig war!
Wir führten daraufhin einige weitere Versuche durch und stellten fest, daß bei der Verwendung von V.42bis sogar die Größe des ersten Paketes (für das Packet-Pair-Verfahren) einen sehr starken Einfluß auf die gemessene effektive Bandbreite hat. Aus diesem Grunde untersuchten wir das Verhalten bei Datenpaketen mit 200 Bytes und verschieden große Werten für das erste Paket.
Da es aufgrund der großen Schwankungen keinen Sinn hat, einen arithmetischen Mittelwert für jede Meßreihe zu verwenden, verglichen wir die Häufigkeitsdichte der gemessenen Bandbreite. Eine graphische Gegenüberstellung für verschiedenen Messungen ist in der Abbildung [ppp-bandw-v42bis-dens-1] zu sehen.
Es fällt sofort auf, daß zwei extreme Werte für die gemessene Bandbreite auftreten. Erstaunlich ist hierbei, daß die Bandbreite sogar die der physischen Modemverbindung um fast das Doppelte übersteigt. Eventuell könnte das auf das Kompressionsverfahren hindeuten, jedoch scheint dies recht unwahrscheinlich zu sein, da die versendeten Daten bereits komprimiert waren (wir verwendeten Daten aus einer gziped Daten, genauer die gziped'te PostScript Daten der V.42bis Recommendation). Aus diesem Grunde betrachteten wir das Verhalten bei einer anderen Paketgröße, wie in Abbildung [ppp-bandw-v42bis-dens-2] gezeigt.
Bei diesen Werten scheint das Verhalten noch weit aus extremer auszufallen. Es zeigen sich deutlich mehrere Maxima, bis zu über 25 kbit/s. Der Grund scheint wiederum die maximale Größe der LAP-M HDLC Frames zu sein, die versendet werden können.
Speziell bei der Verwendung von V.42bis haben wir jedoch gesehen, daß die Messungen direkt keine Hinweise auf die Bandbreite zulassen (vgl. [ppp-bandw-v42bis-dens-2]). Das Bilden eine Mittelwertes führte hierbei zu keinem brauchbaren Ergebnis. Unser Ziel war es jedoch, ein Verfahren zu finden womit wir anhand von Messungen auf die tatsächliche effektive Bandbreite schließen können.
Im folgenden beschreiben wir eine Methode, die dennoch eine sehr gute Schätzung der effektiven Bandbreite zuläßt.
Aus diesem Grunde beschreiten wir nun einen etwas anderen Weg. Zunächst müssen wir die Meßergebnisse bei verschieden großen Datenpaketen normieren. Hierzu müssen wir nur den Overhead, der durch die Protokoll-Header hinzukommt bei den Messungen mit berücksichtigen.
Der Grund, weshalb das sinnvoll ist, ist folgender: Unser Ziel ist es, die Bandbreite einer Verbindung bestimmen zu können, und diese Information wiederum für unsere Format-Wandlung zu benutzen. Die Messungen sollten auf jedem Fall in der PPP-Implementierung realisiert werden. Das heißt auch, daß wenn wir ein Paket empfangen wir alle Header und Trailer mit empfangen. Wir messen also wirklich das, was "durch die Leitung paßt".
Wir definieren also die angenommene effektive Bandbreite E unter Berücksichtigung des Protokoll-Overheads O, bei einer Nutzdatengröße von n wie folgt:
E(n) = B(n) * (O - n) / n |
Angewandt auf unsere Messungen (mit Ausnahme der mit V.42bis) müßte diese Gleichung eine Gerade ergeben, die in etwas waagerecht verläuft. Die Abbildung [ppp-bandw-v42-norm] zeigt das Ergebnis für die Messungen mit V.42 aus Abschnitt [v42].
Es ist deutlich die geradenähnliche Form zu erkennen. Die Schwankungen im unteren Bereich sind auf statistische Abweichungen zurückzuführen.
Wir können somit diese Gleichung nehmen, um unsere Messungen zu Normieren, und auf die tatsächliche effektive Bandbreite schließen.
Nachdem wir die tatsächliche effektive Bandbreite bestimmen können, betrachten wir die kumulierten Häufigkeiten (auch empirische Verteilungskurve genannt) der gemessenen Bandbreite. Der Theorie nach zu folge müßte die Bandbreite, bei der das 0,5-Quartil liegt, der real zur Verfügung stehenden Bandbreite entsprechen.
Wir verwenden hierzu Quantisierungsstufen von 0,1 und stellten die Kurven für die Messungen der letzten Abschnitte bei V.42 und V.42bis zusammen in der Abbildung [ppp-bandw-cum] dar.
Bei der Betrachtung der Kurven fällt folgendes auf: Bis zu dem Punkt, an dem die reale effektive Bandbreite liegt, laufen die beiden Kurven nahezu synchron, auch wenn sie ein wenig versetzt sind. Nach dem 0,5 Quartil weicht die Kurve für V.42bis extrem von der für V.42 ab.
Die Kurve für V.42 entspricht auch exakt den Erwartungen für eine empirische Verteilungsfunktion. Daß die zweite Kurve im oberen Teil derart abfällt war ebenfalls zu erwarten, da sich hier die vielen verschiedenen Peaks in den oberen Bereichen bemerkbar machen.
Der wichtigste Punkt ist jedoch, daß das 0,5 Quartil bei beiden sehr eng beieinander liegt. Mit Hilfe dieser Erkenntnis haben wir nun ein Verfahren zur Verfügung, mit dem wir die reale effektive Bandbreite durch Messungen ziemlich gut approximieren zu können.
Wir können somit folgende Aussage treffen: Die zu reale effektive Bandbreite kann durch Messungen bestimmt werden, und ist der Wert am 0,5-Quartil der empirischen Verteilungsfunktion der Bandbreite.
Die Messungen wurden bisher jedoch nur in einer optimalen Umgebung durchgeführt. Die Frage, in wie weit dieses Verfahren auch in einer realen Umgebung zu verwenden ist, werden wir später in unserer Testimplementierung (Kapitel [testImpl]) noch klären.