Re: PPPoE Performance Problem

From: Bernd Walter <ticso(at)cicely7.cicely.de>
Date: Tue, 18 Nov 2008 12:55:50 +0100

On Tue, Nov 18, 2008 at 12:30:29PM +0100, Hellmuth Michaelis wrote:
> Am Tuesday 18 November 2008 schrieb Matthias Teege:
> > > Zudem habe ich den Verdacht, dass hier noch andere Dinge eine Rolle
> > > spielen - ein Router, der ausgelastet ist ist nicht 80% idle.
> > > Da werden dann einfach keine Packete zum routen kommen.
> > > Evtl. ist ja der DSL gestört und es gehen Packete verloren.
> >
> > Ich vermute das auch. Es ist kein Problem, die Kiste mit
> > Routing zuzumachen, wenn ich Daten zwischen zwei 100MBit/s
> > Netzwerkschnittstellen übertrage. Die niedrige Last bei PPPoE ist mir
> > momentan unerklärlich. Ich werde das System mal auf mpd5 umstellen, was
> > wohl "prinzipiell" eine gute Idee ist, und es dann mal zur Beobachtung ein
> > paar Tage laufen lassen. Eventuell sind Paketverluste das Problem. Das
> > Geschwindigkeitsproblem tritt ja nur in eine Richtung auf. Der Upstream
> > ist in beiden Fällen identisch, wenn, logischerweise, auch deutlich
> > niedriger.
>
> Vor ca. einem Jahr habe ich privat von DSL 6000 auf DSL 16000 umgestellt.
> Bis dato lief auf dem Gateway ein FreeBSD mit einem userland-PPP zur
> vollen Zufriedenheit und störungsfrei.
>
> Nach der Umstellung war alles anders. Ich bekomm's nicht mehr so recht
> zusammen, das größte Problem sind offenbar ACK's, die verzögert über den
> langsamen ADSL Rückkanal rausgehen, auch verursacht durch die Laufzeiten,
> die beim mehrfachen Übergang Kernel-Userland in der userland-PPP Umgebung
> auftreten.
>
> Es gibt Seiten im Internet, die sich mit dem Bau einer separaten HiPri
> ACK-Queue unter PF und OpenBSD beschäftigen, um das Problem in den Griff
> zu bekommen.
>
> Damals bin ich vom userland-PPP auf mpd4 umgestiegen, der die userland/
> kernel Übergänge (und den damit verbundenen unvermeidlichen Overhead)
> vermeidet und bin sehr zufrieden damit - was die Geschwindigkeit angeht.
> Am mpd wird wohl noch viel gebastelt, und ich habe mir mehrfach die Finger
> an neuen (stable) Versionen verbrannt.
>
> Ein weiterer Faktor sind - zu meinem Erstaunen - die DSL Modems gewesen,
> ich hatte in dem Zusammenhang 3 oder 4 Modelle getestet, die teilweise
> merkliche Performanceunterschiede aufwiesen: je neuer (und billiger), desto
> schlechter.

Das ergibt durchaus einen gewissen Sinn.
Man schickt ein Paket auf die Reise und es geht beim FreeBSD schnell
raus, weil das Ethernet schnell ist.
Beim Modem hängt es dann im Sendebuffer, weil die DSL-Verbindung
langsammer ist.
Was macht nun das Modem, wenn der Buffer voll läuft?
Es hat nichts mit IP zu tun und kann auf der Ebene nicht eingreifen.
Also wird es nur verwerfen können - mit einem mehr oder weniger
intelligenten Verfahren.
Auch hier stellt sich die Frage wie groß die Latenz durch den
Modem-Buffer ist.
Einfacher ist es eine dummynet Queue einzurichten und selber knapp
unter der Leitungsbandbreite zu drosseln.
Dann hat man das Nadelöhr selber, kann per IP gezielter eingreifen,
kann priorisieren, wenn es angesagt ist und man hat die Latenz unter
Kontrolle.
Aber bereits die einfache Queue ohne Spezialbehandlung wirkt bei manchen
Modems echt wunder.
Von reinen Ack oder small-packet Priorisierungen halte ich absolut nichts.
Im Gegenteil: Ich halte sowas für eine graussamme Verschlimmbesserung.
TCP ist nicht darauf ausgelegt, dass Pakete in der Reihenfolge vertauscht
werden.

> Nachdem dann alles soweit OK war, hatte ich dann nur noch auf meinem IPsec
> VPN-Tunnel in die Firma eine grottenschlechte Performance. Es stellte sich
> hier nach langem Suchen heraus, das das Netzwerkinterface zum DSL Modem
> dann und wann mal ein Paket verlor (was es offenbar schon immer gemacht
> hatte). Ein Austausch gegen ein fxp-interface heilte alle Wunden .. :-)

Klingt nach klassischem Duplex-Problem.
Eine 16'er ADSL kann durchaus schon mal auf einem 10M Interface eine
spürbare Anzahl von Kollisionen verursachen - wenn nun die Duplex
Einstellung nicht übereinstimmt sind halt Pakete weg.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 18 Nov 2008 - 12:56:01 CET

search this site