Maximal möglicher Durchsatz bei ax.25


(Optisch und rechtschreiberisch leicht überarbeitete Version. Das Original ist weiterhin verfügbar. Der Artikel erschien zuerst im ADACOM-Magazin(ext.Link))
Hin und wieder stellt sich die Frage, wie hoch der maximale Durchsatz an Nutzdaten bei einer gegebenen Brutto-Übertragungsrate sein kann.

Wir betrachten dazu zunächst die Verhältnisse in einer 9600-Bit/s Verbindung auf einer freien und absolut störungsfreien Frequenz. Beide Stationen sind gleich ausgestattet, ihre Knotenrechner sind hinreichend schnell, so daß es auf Grund der Protokollbearbeitung keine Verzögerung gibt.
Da sie alleine auf einer Frequenz sind, brauchen sie auf andere Stationen keine Rücksicht zu nehmen und verwenden "Kampfparameter".

In ax.25 werden die Daten üblicherweise in einer "geschalteten Verbindung" (virtual circuit) übertragen. Das garantiert, daß die Daten komplett und in der richtigen Reihenfolge beim Empfänger ankommen.

Die geschieht mit Hilfe von Infopaketen (I-Frames), die die eigentliche Informationen transportieren sowie Überwachungspaketen (Supervisory-Frames), die für die Bestätigung der Infopakete und ggf. deren Wiederholung sorgen.

Im Idealfall der störungsfreien Übertragung können vom Sender bis zu 7 Pakete mit einem Nutzinhalt von jeweils bis zu 256 Bytes an einem Stück gesendet werden. Danach muß der Empfänger den korrekten Erhalt der 7 Pakete durch ein kurzes Überwachungspaket (RR-Frame) bestätigen.

Das sieht dann in etwa so aus:

 TX:  1.I-Paket   256 Byte Nutzdaten
 TX:  2.I-Paket   256 Byte Nutzdaten
 TX:  3.I-Paket   256 Byte Nutzdaten
 TX:  4.I-Paket   256 Byte Nutzdaten
 TX:  5.I-Paket   256 Byte Nutzdaten
 TX:  6.I-Paket   256 Byte Nutzdaten
 TX:  7.I-Paket   256 Byte Nutzdaten
                                       RX:  RR-Paket für 1.-7. I-Paket
 TX:  8.I-Paket   256 Byte Nutzdaten
 TX:  9.I-Paket   256 Byte Nutzdaten
 ...(usw.)
 
In einem Sendedurchgang können also 7 * 256 = 1792 Byte Nutzinhalt transportiert werden. Bei 8 Bit pro Byte sind dies 14336 Bit Nutzinhalt. Dieser Sendevorgang "kostet" insgesamt 8 Pakete sowie Ein- und Ausschalten des HF-Sender von Sender und Empfänger.

Jedes ax.25-Paket enthält Kopfinformationen (Header), welches das Zielcall (Adresse) des Pakets, seinen Absender sowie evtl. bis zu 8 Zwischenstationen (Digis) enthält.

Jedes Call benötigt 7 Byte. Sechs Byte sind für das eigentliche Call erforderlich, das 7.Byte enthält die SSID sowie einige Steuerinformationen.

Ausserdem gibt es noch ein Kontrollbyte, das angibt welcher Pakettyp vorliegt und welches I-Paket gesendet wird, bzw welches Paket bestätigt wird.

I-Pakete verfügen ausserdem noch über ein Byte PID (Protokoll IDentyfier). Es gibt die Art des Inhalts der I-Pakete an. Die häufigsten PID-Werte sind f0 (hex) falls kein besonderes Protokoll vorliegt sowie cc (hex) für TCP/IP. Das PID-Byte zählt nicht als Nutzdatum.

Wir haben also 8 Pakete. Jedes Paket hat also einen Header mit einer Länge zwischen

      2*7=14  (Absender Call und Ziel Call)
           1  Kontrollfeld
     --------
          15 Byte
und
 
  (2+8)*7=70  (Absender Call und Ziel Call, sowie 8 Zwischenstationen)
           1  Kontrollfeld
  -----------
          71 Byte
Wir begnügen uns mit dem kürzeren Adresse als Beispiel. I-Pakete haben noch ein Byte mit der PID zusätzlich, so daß wir auf insgesamt
  8 Paket * 15 Byte (Header) + 7 * 1 (Byte PID) = 127 Byte = 1016 Bit
                                                             ========
ax.25-Header für unsere 14336 Bit Nutzdaten kommen.

Allerdings sind wir damit noch lange nicht auf dem Sender. Denn es fehlen noch

Für beides sorgt das HDLC-Format (High Level synchronous Data Link Communication, manchmal auch als SDLC bezeichnet).

Dazu wird jedes ax.25-Paket in einen HDLC-Rahmen (Frame) verpackt. An das Ende des ax.25 Paket wird eine 2-Byte Prüfsumme angehängt. Dahinter und auch vor das erste ax.25 Bit wird ein bestimmtes Bitmuster (Flag) von 8 Bit Länge gesetzt (01111110). Es wird nun dafür gesorgt, daß zwischen diesen beiden Flags - also in den Daten selber - kein weiteres Flag mehr auftauchen kann.
Sind dort irgendwo fünf "Einsen" hintereinander vorhanden, so muß nach der 5. "Eins" eine "Null" eingefügt werden. Dies nennt man Bit-Stuffing (Füllung).

Die Anzahl der einzufüllenden Bits ist von dem Typ der Daten abhängig. Experimente ergaben, daß mit etwa 0,1 % (Textdateien) bis 1,5% (komprimierte Dateien) Stopfbits zu rechnen ist. Die theoretische Obergrenze liegt bei 20%, wenn nämlich der gesamte Inhalt aus "Einsen" besteht. Die Experimente bezogen sich allerdings nur auf die Nutzdaten, und nicht auf die ax.25-Header. Aufgrund der Adresscodierung kann man davon ausgehen, daß in ax.25-Headern auf 56 Bits maximal 1 Bit gestufft wird. Das wären immer noch unter 2%.

Sind mehrere Rahmen direkt hintereinander, so kann das Ende des ersten Rahmens gleichzeitig als Anfang des zweiten Rahmens dienen. Dies wird offenbar nicht häufig ausgenutzt, ist aber zulässig.

Wir haben also 14336 Bit Nutzdaten + 1016 Bit ax.25-Header. Hinzukommen für die 8 Pakete jeweils 16 Bit Prüfsummen. Die sind 14336+1016+8*16 = 15480 Bit

Diese Daten werden gestopft. Dies ergibt

 15480 * 1,5 % = 232 Bit
Stopfbits.

Jetzt kommen noch die Blockbegrenzer. Diese sind für diese 8 Pakete insgesamt 10 Begrenzer je 8 Bit = 80 Bit.

Bislang haben wir also 15480 + 232 + 80 = 15792 Bit mit denen die 14336 Bit Nutzdaten übertragen werden. Das sind 9,2 % Overhead. Das wären 8714 Bit/s bei einem üblichen 9600 Bit/s Einstieg.

Aber noch sind wir nicht auf dem Sender.

Bevor wir auf den Sender dürfen, müssen wir abwarten bis die Frequenz frei ist (wir gehen von einem Simplex, Nicht-DAMA Einstieg aus).

Dies bestimmen die Parameter Persistance und Slottime bzw. DWait. Für die einfachere Rechnung verwenden wir hier nur den Wert DWait. Fred, DC6IQ zeigte in [1] wie man zwischen diesen Parametern umrechnen kann.

Ist die Frequenz frei, so kann man den Sender einschalten. Bevor aber der erste HDLC-Rahmen gesendet werden kann, muß der Sender erst bereit sein. Diese Latenzzeit muß man abwarten. Wir nennen sie *TXDelay*.

Nach dem Senden des letzten HDLC-Rahmen gibt es analog zu TXDelay meistens noch ein Sender-Abklingzeit. Wir nennen sie *TXTail*.

Diese Zeit DWait+TXDelay+TXTail geht zweimal - nämlich jeweils für die Sendung von Sender und Bestätigung des Empfängers von der nutzbaren Zeit ab. Da wir einen maximalen Durchsatz erreichen wollen, stellen wir dazu "Kampfparameter" ein:

   DWait    10 ms
 TxDelay    40 ms
  TxTail    10 ms
 ----------------
            60 ms
Wir drücken sie sinnvollerweise in Anzahl nicht nutzbarer Bits aus:
  9600 bit
       ---  * 0,06 s = 576 Bit.
        s
Diese Verzögerung tritt zweimal auf.
  15792 + 2 * 576 = 16944 Bit
mit denen die 14336 Bit Nutzdaten übertragen werden.

Jetzt sind wir endlich auf dem Sender und können bilanzieren:

   16944 Bit Brutto
 - 14336 Bit Netto
  -----------------
    2608 Bit
oder 18,2 % Overhead oder 81,8% effektiv. Dies sind bei 9600 Bit/s
    7854 Bit/s effektiv
Verwendet man vernünftige Parameter, z.B. DWAIT 400 ms gibt es direkt 0,390 s * 9600 bit/s = 3744 Pseudobit dazu, was dann zu einem Overhead von insgesamt 44,3 % führt, entsprechend 5346 Bit/s eff. Datenrate. Aber man lässt dann auch im echten Betrieb noch andere HAMs ran.

Allgemeine Formel

Wir wandeln nun die gemachten Aussagen in eine allgemeine Formel um:
      o = max. Anzahl unbest. I-Pakete (1 bis 7, typisch 7)
    mpl = max. Nutzlänge eines I-Pakets (1 bis 256, typisch 256)
 nDigis = Anzahl der Digis in der Adresse (0 bis 8, typisch 0..2)
    bpc = Bytes pro Call im ax.25-Header (6 Byte Rufzeichen + 1 Byte SSID = 7)
     sr = Stuffingrate. Abhängig vom Dateiinhalt (0 bis 0,2 , typisch 0,01)
  DWait = in s
 TxTail = in s
TxDelay = in s
     Bd = Datenrate brutto der Übertragungsstrecke in Bit/s
Anzahl der Nutzdaten Bits:
 AND = 8 * o * (mpl+1)
Anzahl ax.25-Header-Bits
 A25H = 8 * (o+1) * ( (2+nDigis)*bpc + 1 )
                                       ^ Kontrollfeld
Anzahl HDLC Bits
 AHDLC = ( AND+A25H + 2*(o+1) ) * (1+sr) +    8 * (o+1+2)
                       CRC       Stuffbits  Blockbegrenzer
Anzahl der "Pseudobits" wg. Latenzzeiten
 APB = 2 * (Dwait+TxDelay+TxTail) * Bd
Gesamtformel also:
                    AND
  effBaudrate = ----------- * Bd
                APB + AHDLC

Welche Verbesserungen sind möglich?

  1. Anzahl der Nutzdatenbits (AND) erhöhen.
  2. Verringerung der Header-Grösse (A25H)
  3. Verringerung der Latenzzeiten (APB)
Bei hohen Datenraten stellen die Umschaltvorgänge zwischen Senden und Empfangen die grösste Bremse dar. Man muß daher versuchen die Anzahl der Umschaltungen verringern (Maxframe erhöhen) oder auf solche Umschaltungen seitens des Senders verzichten (Duplex, Optima).
[1] Fred Baumgarten, DC6IQ, "Parametrieung von FlexNet-Digipeatern", Adacom Magazin, 3/92