OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
DL8HBS > DIEBOX   20.06.97 21:36l 74 Lines 3332 Bytes #-10495 (0) @ DL
BID : EC38AIDL8HBS
Read: GUEST
Subj: RE:Router-Chaos !?
Path: OE1XAB<OE3XPR<OE3XPR<OE1XBB<OE3XYW<OE3XSR<DB0RGB<DB0ABH<DB0SRS<DB0SIF<
      DB0NHM<DB0SAW<DB0TGM<DB0BLO<DB0GR
Sent: 970620/1918z @:DB0GR.#BLN.DEU.EU [Berlin-BBS OP:DL7QG] DP5.07 $:EC38AIDL8
X-Info: User S&F received from DL8HBS at DB0GR
From: DL8HBS @ DL8HBS (Joachim)
To  : DIEBOX @ DL

Hallo,

ich moechte insbesondere DK2GO's Hinweise zur Anzeige und dem
tatsaechlichen Routing einer DIEBOX nochmal unterstreichen.

Andererseits wird hier ein grundsaetzliches Problem sichtbar:
Aufgrund welcher Analyse soll ein Box-Autorouter arbeiten?

Die DieBox-Methode, die Route mit den wenigsten Hops zu waehlen,
ist eine Moeglichkeit. Sie stammt wohl urspruenglich aus dem
Internet und hat dort durchaus ihre Berechtigung. Natuerlich ist
dies eine sehr rudimentaere Form, guenstige Uebertragungskanaele zu
bestimmen.

Wie DK2GO schrieb, gehen viele Fehlerquellen in die Berechnung ein,
die wesentlichste ist die Nichtbeachtung der Kanalbandbreite.

Der von DPBOX verwendete Algorithmus geht wieder anders vor: es
werden anhand der Zeitstempel in den Forward-Headern die Laufzeiten
von Mails gemittelt (gemittelt!). Das scheint fuer nicht
drahtgebundene und instabilere Netze schon eine zuverlaessigere
Methode zu sein. Um Schwankungen im Nachbarbereich zu
unterdruecken, geht zusaetzlich die Anzahl der Hops als
"Verschlechterer" in die Berechnung ein. Zusaetzlich veralten die
Werte nach einem dynamischen Parameter. Eine extrem gute Route von
letzter Woche muss heute nicht besonders stabil sein.

Wuerden alle Router mit demselben Algorithmus laufen, koennte man
damit schon recht zufriedenstellend arbeiten. Leider gehen auch
hier Fehlerquellen in die Berechnung ein: Etliche Boxuhren beachten
keine Sommerzeit oder aehnliches und verschlechtern so die
Qualitaet einer an sich recht guten Strecke. Der Algorithmus
buegelt zwar falsche Zeitstempel aus, aber das Resultat ist meist
eine Verschlechterung der Laufzeit.

Da nun DIEBOX einen anderen Algorithmus benutzt und FBB sowie
BayBox gar kein Autorouting kennen, wird das Ergebnis aber immer
den Erwartungen hinterherhinken.

Mein persoenliches Fazit daraus ist, in keinem Fall Autorouting als
Basis des gesamten Box-Routings zu verwenden (es sei denn, man hat
nur zwei Forward-Partner, dann klappt es recht gut), sondern die
ueblichen Definitionen durch den Sysop vorzunehmen und den
Autorouter nur fuer "Luecken" zu verwenden. Es ist eine Schwaeche
von BayBox, dass dort jede neue BBS im eigenen Bundeslandkenner
eingetragen werden muss (natuerlich ist es kein Problem, wenn der
Sysop sie schnell genug eintraegt), bei DieBox und DPBOX ist dieses
Problem unbekannt. Meines Erachtens ist das Autorouting einzig fuer
diese kleinen Luecken sinnvoll, und gegebenenfalls um dem Sysop
einen Hinweis zu geben, dass die festeingestellten Routen
unguenstig gewaehlt sein koennten.

Der typische Fehler eines Sysops sowohl bei DIEBOX als auch DPBOX
ist, dem Autorouting blind zu vertrauen. Es kann unter den
gegebenen Bedingungen nicht wirklich gut funktionieren. Definiert
alles, was ueblich ist, und lasst einfach die verbleibenden Luecken
durch den Router ausbuegeln.

Wirklich gut wuerde das Autorouting nur funktionieren, wenn sich
die Boxen in einem eigenen Protokoll ueber die Qualitaeten zu
Nachbarn verstaendigen wuerden.

Mit dem oben geschilderten Analyseverfahren von DPBOX ist
vermutlich das Optimum dessen erreicht, was sich autonom von einer
mitlesenden Software erreichen laesst. Eine wirklich ueberzeugende
Loesung bietet auch dieses nicht.

73 Joachim, DL8HBS


Read previous mail | Read next mail


 16.03.2026 02:55:17lGo back Go up