| |
DO2UKW > LEXIKON 20.10.05 00:34l 383 Lines 18788 Bytes #999 (0) @ DL
BID : JAFDB0GOS0DS
Read: GUEST DG5YMS DK8MW DK7NR DB2OY
Subj: Para P + W
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0IUZ<DB0GOS
Sent: 051019/2156z @:DB0GOS.#NRW.DEU.EU [Essen, JO31LJ] obcm1.06b52
From: DO2UKW @ DB0GOS.#NRW.DEU.EU (Phil)
To: LEXIKON @ DL
X-Info: No login password
WA8DED-Firmware
===============
Die Befehle P und W
-------------------
Immer wieder kommen Fragen von Einsteigern: wie geht das mit PR,
wie connecte ich einen Digi, wie gehe ich mit der Box um.
Genausowichtig fuer den geordneten Betrieb ist aber auch die
richtige Wahl der Parameter. Sind diese falsch eingestellt, so
leidet der Datendurchsatz. Andere Stationen werden, fast immer
ungewollt, behindert, indem sie beiseitegedrueckt werden. Das ist
der haeufigste Fall. Die falsche Wahl der Betriebsparameter kann
jedoch auch dazu fuehren, dass eine Funkverbindung erst gar nicht
zustandekommt.
Um das Verstaendnis dafuer etwas zu vergroessern, will ich in
loser Reihenfolge allgemeinverstaendlich erklaeren, was es mit den
verschiedenen wichtigsten Parametern auf sich hat, was sie
bewirken und wie sie fuer 1200 Baud Simplex optimal eingestellt
werden.
Alle Angaben beziehen sich auf eine der haeufigsten Hardware
Konfigurationen: auf ein unmodifiziertes TNC2 mit WA8DED-Firmware
(verschiedene Versionen) mit einem Hostmode- oder Terminal
Programm. Den Kiss-Mode beruecksichtige ich nicht, hier
funktioniert alles anders. Die meisten Kiss-Mode-Programme (z. B.
Superkiss) liefern in der Dokumentation auch recht gute
Erklaerungen und vor allem komplette Listen mit moeglichen
Befehlen mit.
Eventuelle Unterschiede zwischen TNC2 im Host- und Terminalmode
werde ich erlaeutern, sie sind jedoch fuer die Betriebsparameter
minimal.
P - die PERSISTANCE / W - die Slottime
--------------------------------------
Dies sind die beiden Parameter, die haeufig fuer Verstimmung
sorgen. Wenn OM Waldheini auf dem Digi auftaucht, herrscht fuer
andere Funkstille, fuer OM Waldheini geht alles ruckzuck, die
anderen OM bekommen ihre Packets nur noch troepfchenweise.
OM Waldheini faehrt wahrscheinlich "harte Parameter" und ist
obendrein sehr gut beim Digi zu hoeren.
Verantwortlich fuer die "Sendefreudigkeit" des TNC2 sind zwei
Parameter: PERSISTANCE und SLOTTIME, P und W.
Das TNC2 geht nicht einfach so auf Sendung, wenn die Frequenz frei
ist. Es wuerfelt gleichermassen aus, ob es nun sendet oder nicht.
Der Wert P kann im TNC zwischen 0 und 255 eingestellt werden. Nach
einer bestimmten Zeit ermittelt das TNC2 eine Zufallszahl zwischen
0 und 255. Nun vergleicht es diese "gewuerfelte" Zahl mit der
Persistance. Ist die Zahl niedriger als die eingestellte
Persistance, geht das TNC sofort auf Sendung. Ist die Zahl dagegen
gleich oder hoeher, geht das TNC nicht auf Sendung und wuerfelt
nach einer bestimmten Zeit nochmals. Wird nun die Persistance auf
128 eingestellt, so ist diese Chance ungefaehr 50:50. Wird sie auf
10 eingestellt, so muss das TNC im Schnitt ungefaehr 25 mal
"wuerfeln", bis es auf Sendung gehen darf. Stellt man die
Persistance auf 0, so wird es niemals auf Sendung gehen, weil die
ermittelte Zufallszahl ja nicht niedriger als 0 sein kann.
Also: Je niedriger die Persistance, desto laenger braucht das TNC,
bis es auf Sendung gehen kann.
Welche Zeit benutzt nun das TNC, um erneut zu wuerfeln? Diese
Zeitspanne wird mit W festgelegt. Wird W auf 0 festgelegt, so
tritt der Timer nicht in Aktion, es wird also unendlich oft
gewuerfelt, das TNC geht in jedem Falle sofort auf Sendung, als
sei die Persistance mit 255 festgelegt. Nun wird auch klar, wieso
diese beiden Parameter zusammengehoeren, ueber die
Sendefreudigkeit entscheidet nicht nur der Wert von P, sondern
genauso der von W. W 1 bedeutet, es wird alle 10 Millisekunden,
also 100 mal pro Sekunde ausgewuerfelt. W 100 bedeutet, es wird
jede Sekunde ermittelt, ob das TNC nach dem P-Wert auf Sendung
gehen darf. W kann auf Werte zwischen 0 und 127 eingestellt
werden.
Man kann sogar genau ausrechnen, wieviele Sekunden das TNC
durchschnittlich braucht, um auf Sendung zu gehen!
Bei P 128 und W 50 wird das TNC mit 50-prozentiger
Wahrscheinlichkeit nach einer halben Sekunde auf Sendung gehen,
mit 25-prozentiger Wahrscheinlichkeit wird es nach einer Sekunde
auf Sendung gehen, mit 12,5-prozentiger Wahrscheinlichkeit wird es
nach 1,5 Sekunden auf Sendung gehen usw. Meistens wird es also
eine kleine Weile brauchen, um die PTT zu betaetigen. In dieser
Zeit koennen andere Stationen zum Zuge kommen, es kann aber auch
passieren, dass der Digi wieder zu senden anfaengt. Nicht schlimm,
der geht ja auch wieder auf Empfang und es wird sicherlich beim
naechsten oder uebernaechsten Mal klappen, dass der Digi die
eigene Aussendung empfaengt.
Wie stellt man P und W nun vernuenftig ein und wozu ist diese
kuenstliche Sendeverzoegerung gut?
W ist voreingestellt mit 10 im TNC, solange man nichts anderes
eingibt, P mit 64 (das kann je nach Version aber auch anders sein,
einfach ueberpruefen mit <ESC> W und <ESC> P, das TNC2 spuckt die
Zahlen dann postwendend aus). Das sind ganz vernuenftige Werte.
Sie verhindern oft, dass Stationen, die sich nicht hoeren,
gleichzeitig senden und sich dadurch stoeren. Senden sie zufaellig
in einem Durchgang gleichzeitig, so wird das im naechsten
Durchgang wahrscheinlich nicht mehr so sein. Wenn allerdings sehr
viel Betrieb herrscht, sollte man die Werte reduzieren. Bei W 10
lautet die Faustregel: P = 255 durch Anzahl der Stationen auf dem
Digi. Ist man alleine kann man P 255 benutzen, ist eine andere
Station da, sollte man P auf 128 reduzieren, um der anderen
Station eine Chance zu lassen, vor allem wenn man den Digi selber
recht gut erreicht. Bei 10 Stationen sollte man P 25 benutzen, bei
20 Stationen kann man P schonmal auf 10 reduzieren. P haengt also
sehr von der Belegung des benutzten Kanals ab und sollte von Hand
dem Betrieb angepasst werden.
Nur keine Bange: wenn von 20 Stationen 5 "Krokodile" immer sofort
nach dem Digi auf Sendung gehen, kann man ruhig abwarten. Die
Frequenz wird dann naemlich wieder ruhig und man selbst bringt
sein Paket ungestoert zum Digipeater. Ich habs ausprobiert: bei
viel Betrieb kommt man mit "weich" eingestellten Parametern sehr
oft besser zum Zuge, als wenn man mit der Meute bruellt. Und je
mehr Stationen sich daran beteiligen, desto besser wird der
Datenfluss fuer alle sein - insbesondere auf Duplex-Digipeatern.
Nun wirds speziell: die Streuung.
Wer aufmerksam mitgerechnet hat, wird sicherlich bemerkt haben,
dass die Kombination P 10 / W 5 genauso sendfreudig ist wie P 100
/ W 50 oder P 50 / W 25. Je niedriger man P und W waehlt bei
gleichem Verhaeltnis zueinander, desto feiner wird der Start der
Aussendung verteilt. Bei W 50 kann der nur zur halben Sekunde
erfolgen, waehrend bei W 5 immerhin 20mal pro Sekunde "gewuerfelt"
wird, allerdings ist da durch die niedrigere Persistance die
Wahrscheinlichkeit niedriger, dass das TNC auf Sendung geht, es
wird im Schnitt genausolange brauchen. Damit kann man getrost
experimentieren, ich persoenlich bevorzuge die bessere Verteilung
weil ich meine, dass ich damit eher mal eine Luecke treffe, in der
niemand anders sendet.
P und W muessen jeweils getrennt eingestellt werden, nicht dass
das Missverstaendnis aufkommt, wenn man P aendert, aendert sich W
mit, so intelligent ist das TNC nicht.
Aendern kann man die Parameter, indem man eingibt:
<ESC> P n wobei n zwischen 0 und 255 liegen kann, sowie
<ESC> W n n kann hier zwischen 0 und 127 liegen (TF V 2.1)
Persistance funktioniert auch in anderen Programmen aehnlich, im
Kissmode kann P auch ersetzt sein durch DWait, im Unterschied zu
den obigen Ausfuehrungen ist das eine simple Konstante.
Auch der Digi kennt P, er hat eine eigene Persistance. Auch die
sollte uebrigens dem Betrieb angepasst sein, damit alle Stationen
genuegend Zeit haben, ihre Packets loszuschicken. Dieser Betriebs-
parameter ist vom User ueblicherweise abfragbar.
T - TX-Delay (Sendeverzoegerung)
--------------------------------
TX-Delay ist einer der Paameter, die am haeufigsten falsch gesetzt werden.
Meistens liegt der Wert viel zu hoch und belegt dadurch unnoetig die
Frequenz.
Man merkt meist nicht viel davon, wenn eine andere Station diesen Parameter
zu hoch einstellt, es geht nur ganz allgemein etwas schlechter.
TX-Delay legt die Zeit fest, die zwischen Dem Tasten der PTT und dem Beginn
der eigentlichen Datenuebertragung liegt. Notwendig ist das deshalb, weil
alle Transceiver eine gewisse Verzoegerung beim Einschalten benoetigen, um das
erste Paket eines Rahmens (Rahmen = Aussendung einer Reihe von Frames, ohne
dass die PTT freigegeben wird) fehlerfrei uebertragen zu koennen. Ohne TX-Dleay
wuerden hier immer einige Bit verschluckt vom TRX und es wuerde nicht
funktionieren.
Damit es auch sicher funktioniert, stellt man TXDELAY gerne ein wenig hoeher
ein als notwendig. Aber das fruchtet nichts. Es gibt nur einen richtigen
Wert fuer TX-Delay, und das ist der, bei dem der Digi einen gerade noch hoert.
Mehr ist unnoetig, weniger waere nicht gut.
Wie hoch stelle ich also TXDelay ein?
Mehr als 30 ist m. W. bei den gaengigen Geraeten (auch Handies) nicht
notwendig. Einige schnelle Geraete schaffen sogar Werte um 2.
TXDelay 1 bedeutet 10 msec. Verzoegerung, 10 waere 0,1 Sekunde, 100 also eine
volle Sekunde.
Man kann den Wert experimentell sehr leicht ermitteln:
Man sucht eine ruhige Stunde und schickt UI-Frames via Digipeater.
Das funktioniert folgendermassen:
Man geht auf den Monitorkanal (Kanal 0) und gibt dort den TNC-Befehl
C TEST DIGICALL ein. DIGICALL muss natuerlich durch das Call des Digipeaters
ersetzt werden. Nun schickt man mit RETURN einfach ein leeres Info-Frame
ueber den Digi. Das sieht auf dem Monitor folgendermassen aus:
fm DL8GAM to TEST via DB0FRG ctl UI+
Wenn der Digi DB0FRG dieses Paket empfangen hat, wird er solch ein Paket
ausstrahlen:
fm DL8GAM to TEST via DB0FRG* ctl UI+
Das Sternchen hinter dem Call kennzeichnet, welcher Digi auf dem Weg das
Frame ausgestrahlt hat. Nur so kann eine Gegenstation unterscheiden, ob der
Digi oder die Gegenstation ein Frame gesendet haben.
Wenn das Paket also einwandfrei zurueckkommt ist das ein positives Zeichen,
der Digi hat mich gehoert, also kann TXDelay schonmal nicht zu kurz sein.
Nun frage ich den eingestellten Wert ab, dazu verwende ich den TNC-Befehl T,
eingeleitet werden TNC-Befehle allgemein mit der Taste ESCAPE. Also <ESC> T
eingeben, und schon wird das TNC einen Wert ausgeben, meist 30.
Nun setze ich den Wert herunter, erstmal auf 25 zum probieren. Nun versuche
ich mehrmals, mein UI-Frame via Digi loszuwerden. Mehrfach deswegen, weil
ich ja sicher sein muss, dass nicht gerade QRM meine Aussendung zunichte
gemacht hat. Kommt auch dieses UI-Frame an, setze ich T auf 20 usw.
Ich verringere also so lange den Wert, bis der Digi mich nicht mehr empfaengt.
Dann setze ich den Wert solange hoch, bis der Digi mich gerade wieder
empfaengt. Nun kann ich den Wert zur Sicherheit um 2 oder 3 Stufen nach oben
setzen, also wenn einzelne Pakete mit T 15 noch ankommen, gebe ich T 17 oder
T 18 ein, das reicht in jedem Falle dicke aus.
Meistens liegt der so ermittelte Wert um einiges niedriger, als die
vorherige Einstellung.
Bei Hostmode-Programmen wie THP oder SP kann man den so ermittelten Wert in
die Initialisierungs-Datei eintragen. So wird der richtige Wert immer bei
Programmstart ans TNC geschickt.
Bei Terminal-Programmen bleibt der Wert im TNC gespeichert, vorausgesetzt es
verfuegt ueber eine geeignete (sprich funktionstuechtige, hi!) Pufferbatterie.
Wer mehrere Geraete betreibt: T haengt nicht vom TNC ab oder vom Digipeater,
der gerade benutzt wird sondern ausschliesslich vom Geraet.
Die Vorteile einer richtigen Einstellung liegen auf der Hand:
Geringere Frequenzbelastun
F - der FRACK
-------------
Eingegeben und abgefragt wird der Wert mit dem TNC-Kommando F. Er
kann zwischen 1 und 15 eingestellt werden (eventuell andere Werte
in verschiedenen Firmware-Fassungen).
FRACK gehoert zu den Parametern, die mit dafuer entscheidend sind,
wie oft das TNC auf Sendung geht. FRACK gibt den Takt an, mit dem
"gepollt" wird. Die Angabe erfolgt hier in Sekunden, FRACK 1
bedeutet also jede Sekunde wird gepollt.
Was ist nun dieses Polling?
Es faengt schon beim Verbindungsaufbau an: Das SABM zum
Verbindungsaufbau wird solange gepollt, also unveraendert
wiederholt, bis entweder der Retry-Zaehler (das ist der Zaehler,
der angibt, wieviele Versuche das TNC macht, bevor der Disconnect
eingeleitet wird) abgelaufen ist oder aber die Station antwortet.
FRACK entscheidet nun darueber, wie schnell hintereinandr diese
Poll-Pakete geschickt werden.
Aber auch waehrend einer Verbindung kann es zu Polls kommen,
naemlich dann wenn ein Paket oder die Bestaetigung dafuer nicht
ankam. Nach Ablauf der FRACK-Zeit wird dann nachgefragt.
Das sieht konkret so aus:
fm DL8GAM to DB0FRG ctl I00^ pid F0 - 22.02.91 22:14:12
U
fm DL8GAM to DB0FRG ctl RR0+ - 22.02.91 22:14:19
fm DB0FRG to DL8GAM ctl RR0- - 22.02.91 22:14:20
fm DL8GAM to DB0FRG ctl I00^ pid F0 - 22.02.91 22:14:22
U
fm DB0FRG to DL8GAM ctl RR1v - 22.02.91 22:14:25
Das erste Paket wurde nicht bestaetigt. Also kam nach sieben
Sekunden eine Nachfrage. Diese wurde dann beantwortet (RR0-
bedeutet "Fortfahren mit Paket Nummer 0") und I00^ nochmals gesendet.
Nun bestaetigte DB0FRG das Paket. Die folgende Userliste wollen
wir lieber mal lassen, hi!
(Das sind Originalpakete. Wie man den schoenen Time-Stamp
hinkriegt kommt in Parameterkunde 7 oder 8 oder so... Es gibt noch
wichtigeres...)
Die Nachfrage nach sieben Sekunden resultiert aus der FRACK-Zeit.
Die betrug hier vier Sekunden. Dann ist noch die Slottime und
Persistance wichtig dafuer, wie schnell das TNC pollt. Wer FRACK 4
einstellt und sehr harte Parameter, wird auch alle vier Sekunden
pollen. Wer die Parameter weicher stellt, wird etwas langsamere
Poll-Raten haben.
So funktionierts also. Wie sollte man FRACK nun einstellen?
Dazu muss man weiter ausholen:
Ganz praktisch: Wer ruecksichtslos jede Sekunde pollt, zerstoert
damit fuer andere, die ein schwaecheres oder nur gering staerkeres
Signal haben auf Simplex-Digis jede Chance, ein laengeres Info-
Paket loszuwerden. Bei Duplex-Digis wird er diejenigen
ueberfahren, die ihre Parameter vernuenftig eingestellt haben.
Vernuenftigerweise sollte ein TNC im Normalbetrieb alle 8 bis 10
Sekunden pollen, bei hoher Belegung eines Netzknotens besser noch
etwas mehr, besonders dann, wenn man recht gut an den Digi kommt.
Das bedeutet: ein FRACK von 4 bis 8 ist fair. Alles was
drunter ist, beschleunigt zwar den eigenen Betrieb, behindert aber
andere ueber Gebuehr.
Aber: FRACK ist nicht immer die Pollrate, das ist sie nur im
Direkt-QSO, also von A nach B ohne Digi. Connecte ich nun meinen
Freund DL1XYZ auf DB0KFB mit folgendem TNC-Befehl:
C DL1XYZ DB0FRG DB0KFB
so wird die Zeit, in der gepollt wird, erheblich laenger, als wenn
ich zuerst eingebe C DB0FRG und dann dem Digi sage, wo ich
hinwill.
Das hat historische Gruende: Als die WA8DED entworfen wurde, gab
es nur Level-2-Digipeater. Diese geben einfach nur wieder was
"via" geschickt wird. Es wird im Netzknoten nichts
zwischengespeichert. Die vornehme getrennte Protokollabwicklung
wie bei FlexNet, wo jeder Pfad einzeln bestaetigt wird, so dass
der Digi ankommende Pakete zwischenspeichert und so bestaetigt,
als habe der Empfaenger das Paket schon erhalten, kannte der Autor
der Software noch nicht.
Also musste immer gewartet werden: nicht nur ein Weg hin und
zurueck musste beruecksichtigt werden, sondern der Weg zum Digi,
der vom Digi zur Gegenstation, von dort zum Digi und wieder
zurueck zum Empfaenger. Klar, dass das eine Zeit braucht. Und die
beruecksichtigt die Firmware nun dummerweise, obwohl man in einem
High-Tech-Netz sitzt, wo das nicht mehr noetig ist.
Es gibt fuer diesen Zeitaufschlag sogar eine Formel:
Zeit (Sekunden) = FRACK * (2 * ANZAHL DER DIGIPEATER + 1)
Bei Frack 4 und zwei Digis (FlexNet Regelfall) werden das also
4 * (2 * 2 + 1) = 20 Sekunden anstatt der eingegebenen vier!
Normalerweise kann man FRACK gar nicht so hoch einstellen, ueblich
ist ein Eingabebereich 1 ... 15
Was kann man dagegen tun? Ganz einfach: entweder ich connecte
zuerst den Digi. Dass ich dort eingebe C DL1XYZ weiss mein TNC ja
nicht, es faehrt weiterhin ja nur brav die Verbindung zum Digi,
die Digipeater dahinter kann es nicht "sehen", genausowenig
uebrigens wie die monitorenden Mit-OM...
Oder aber ich setze FRACK auf dem Kanal herunter, wo ich die
Verbindung fahren will. Nehmen wir mal an, ich habe als Default-
Wert auf Kanal 0 FRACK 5 eingegeben. Nun connecte ich aber DL1XYZ
ueber fuenf Digis. Die Pollrate wird entsetzlich lang - fast 60
Sekunden. Darunter leidet jedes QSO. Hier ist es natuerlich
zulaessig, FRACK herunterzusetzen. Ich gehe also auf Kanal 1, wo
ich die Verbindung aufbauen will oder wo sie bereits steht und
gebe z. B. <ESC> F 2 ein. mit <ESC> F pruefe ich den Erfolg der
Aktion, nun sollte eine "2" erscheinen. Und schon gehts zuegiger.
Bei dem eben geschilderten Extremfall mit fuenf Digis waere FRACK
1 wohl eher angebracht. Nur keine Angst, dass man nachher
vergisst, den Parameter wieder zurueckzusetzen: das macht das TNC
ganz von alleine. Sobald die Verbindung getrennt wird, uebernimmt
es die Werte von Kanal 0. Der Default-Parameter fuer FRACK muss
also nicht etwa auf jedem Kanal eingegeben werden, sondern nur auf
Kanal 0, dort wird er fuer alle disconnecteten Kanaele gesetzt.
Man kann das natuerlich auch einmal mit einem <ESC> F pruefen.
Die vorher beschriebenen Parameter T, P und W gelten natuerlich
IMMER fuer ALLE Kanaele, egal wo man sie eingibt. Da unterscheidet
sich FRACK von diesenGrundbetriebsparametern.
Spezialfall:
Lange Durchgaenge z. B. bei Dateiuebertragungen auf einem freien
Direktkanal mit Sendedurchgaengen, die laenger als FRACK sind:
hier sollte FRACK erhoeht werden, um zu verhindern, dass das TNC
noch waehrend des Durchgangs anfaengt zu pollen; das geht
naemlich! Das TNC faengt an, auf die Bestaetigung zu warten,
sobald das erste Paket raus ist! Das merkt man, wenn man
aufmerksam den Monitor beobachtet und dann einige Poll-Pakete
folgenden Formats waehrend der Durchgaenge kommen (z. B. zwischen
6. und 7. Info-Paket eines Durchgangs):
fm DL8GAM to DJ5SQ ctl RR5+
Dann sollte man FRACK heraufsetzen - und schon steigt der
Datendurchsatz mit niedrigerer FRACK-Zeit...
Solch lange Durchgaenge auf Digipeatern sind uebrigens wenig
sinnvoll. Ich habe nicht umsonst von "frei" und "Direktkanal"
gesprochen, hi! Man kann davon ausgehen, dass man - beim
Duplexdigi - die Sache fuer andere extrem zaehe macht mit sehr
langen Durchgaengen oder aber - bei Simplexdigis - schwaechere
Stationen, die man nicht hoert, so sehr unterbuegelt, dass die OM
entnervt aufgeben. Obendrein bekommt man im Simplexbetrieb die
Durchgaenge meist nicht auf den Digi, weil immer eine staerkere
Station da ist, die einem das eine oder andere Packet
verhackstueckt, womoeglich noch mit zu kurzer FRACK, hi!
-eof-
Read previous mail | Read next mail
| |
