- Geodaten
Populäre Irrtümer (Handy, Hacker)
originelle Fußballstatistiken
Jetdaten
Kuriose Briefe 1945
Führungen durch Düsseldorf
- Geodaten
)
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
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 BitStopfbits.
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 Bitmit 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.
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) * BdGesamtformel also:
AND
effBaudrate = ----------- * Bd
APB + AHDLC
Heimatseite
- E-Mail an Walter
- Homepage