#include 'std.incl' # Beliebig viele #-- Nicht zu ändern: (Optisch und rechtschreiberisch leicht überarbeitete Version. Das Original ist weiterhin verfügbar. Der Artikel erschien zuerst im )
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

  • die Prüfsumme
  • Wiederaufsetzungsmöglichkeit bzw. Erkennung von Paketanfang/ende
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.
    • Auf den ersten Blick scheint die Erhöhung der max. Nutzlänge eines I-Pakets die einfachste Möglichkeit zu sein. Der Parameter mpl taucht schliesslich nur einmal in der Formal - und zwar oberhalb des Bruchstrichs - auf.
      Allerdings steigt dadurch die Wahrscheinlichkeit stark, daß ein Infopaket durch eine Störung unbrauchbar wird . Dabei werden direkt mehr Nutzdaten unbrauchbar, die Effizienz sinkt also im realen Betrieb.

    • Erhöhung der maxinalen Anzahl von unbestätigten I-Paketen ist da günstiger. pe1chhl hat einen entsprechenden Vorschlag gemacht und implementiert. Dabei ist Maxframe auf 63 einstellbar. Rob berichtet von guten Ergebnissen.

  2. Verringerung der Header-Grösse (A25H)
    • Flexnet-Kompress
      Das FlexNet-Header-Komprierung verringert die Grösse eines ax.25-Headers auf konstante 3 Byte. Dadurch lassen sich - grade bei den Flexnet-typischen längeren Adressen - erhebliche Headerverkürzungen beobachten.

  3. Verringerung der Latenzzeiten (APB)
    • Optimieren der Stationen
      Durch verwenden von für die Betriebsart geeignete Geräte kann TxDelay minimiert werden. Bei ungeeigneten Geräten ist das TxDelay teilweise länger als die Aussendung selber.

    • DAMA
      DAMA minimiert im Idealfall DWait auf 0. Txdelay und TxTail bleiben aber wie gehabt. Da im obigen Beispiel DWait auf Kampfparameterart auch auf 0 stand, ist scheinbar kein Vorteil erkennbar. Mit DAMA können aber mehrere Stationen sehr gut auf den Digi zugreifen.

    • Vollduplex
      Bei Vollduplex fällt Dwait sofort weg. Bei dauerstrichfesten Sendern (und günstigen Strompreisen :) ) kann man den Sender dauergetastet lassen, so daß auch txdelay und txtail wegfallen.

    • Optima
      Optima soll die Vorteile von Duplexbetrieb erbringen, ohne deren Nachteile.

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