[Berlin-wireless] Stabilität durch Traffic Shaping

[Sven-Ola Tuecke]

Marek,

naja - wenns bei dir richtig was bringt, bau ich es natuerlich ein. Auf deinem 
Geraet ist offenbar bereits die manuell gesetzte qdisc aktiviert, das zeigt 
der "ip link show eth1" ja an. Ohne das S90olsr-prio sollte es so aussehen:

root at sven-ola-gs:~# ip link show eth1
4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:0f:66:c7:87:70 brd ff:ff:ff:ff:ff:ff

Moglicherweise kann ich "tc" ein wenig abspecken und den diversen 
Schnickschnack ausbauen. Der Befehl kann ja allerlei, was mensch nur seltenst 
braucht. Ich guck aber erst nochmal, warum pfifo_fast nix bringt. 
Moeglicherweise sogar ein Fehler in der Implementierung oder es fehlt irgend 
ein "Tu-endlich-was-Befehl".

Grusz ,Sven-Ola

Am Samstag, 26. November 2005 10:26 schrieb Marek Lindner:
> Sven-Ola Tuecke schrieb:
> >Hallo Marek,
> >
> >erstmal vielen Dank!. Das wundert mich allerdings. Ich hatte das gestern
> > in einer laengeren SItzung selbst untersucht und mich eigentlich gegen
> > ein solches Prio-Shaping entschlossen, weil es laengst eingebaut ist.
> >
> >Der olsrd sendet in der FFF standardmaessig mit TOS=16 (siehe olsrd.conf),
> > mit "tcpdump -nvvi eth1" pruefbar. Damit landet er in der sowieso aktiven
> > fast_pfifo-Traffic-Shaping Qdisc im Band 0 (auf Deutch: Pakete mit
> > Type-of-Server==16 haben absolute Prio beim Senden vor allen anderen
> > Paketen ohne irgendwelche TOS-Bytes per Default in Band 1). Guckst du bei
> > deinem Messaufbau nochmal, ob "ifconfig eth1" evt. einen txbufferlen==0
> > anzeigt!? Mit "ip link eth1" sollte auch der pfifo_fast zu sehen sein.
> > Kein txbuffer, kein aktiver pfifo_fast. Der pfifo_fast ist genau so
> > implementiert wie der tc-aktivierte pfifo(mit filterschnickschnack). Er
> > hat nur den Vorteil, dass man olsrd auch vor TOS-Bytes-Prioverkehr noch
> > weiter priorisieren kann.
>
> Mit TOS habe ich sowieso kein guten Erfahrungen gemacht, weil man (im
> allgemeinen) nicht weiß, wer sich daran hält und wer nicht.
> "ifconfig eth1" zeigt kein "txbufferlen" an. Es gibt nur ein txqueuelen:
> 100.
> "ip link show eth1" gibt "mtu 1500 qdisc prio qlen 100" (unwichtiges
> weggelassen) an. Kein pfifo_fast.
> Der Testaufbau geht von A -> B -> C -> D, wobei ohne tc der
> Endlosdownload recht schnell abbricht. Mit tc bricht er nicht ab,
> pendelt sich aber auf einem niedrigen Durchsatz ein (30-40KB).
>
> >Ich wuerde eher dazu tendieren nochmal manuell zu pruefen warum fast_pfifo
> >hier keine bessere Performance als der manuell aktivierte langsam-pfifo
> > hat.
> >
> >Warum der Aufstand? Nun weil der tc-Befehl locker 113.000 Bytes und die 3
> >Module weitere 22.000 Bytes verbraten wuerden. Da es mich die ganze letzte
> >Woche gekostet hat, ziemlich genau soviele Bytes in der FFF einzusparen,..
> > Es gibt noch etliches andere was da noch hineinkoennte...
>
> Versteh ich ja, deshalb wollte ich es erst testen lassen, um zu sehen,
> ob sich ein messbarer Effekt einstellt.
>
> Gruß,
> Marek


-------------- nächster Teil --------------
_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://olsrexperiment.de/cgi-bin/mailman/listinfo/berlin