performance: openbsd router stellt nicht dslbandbreite uebr pppoe zur verfügung

siptec

Member
hallo liebe forenmitglieder,

folgendes szenario:

Computer
Intel p2 450mhz 512mbyte ram
2 netzwerkkarten (1nach intern 1 zum dslmodem)
openbsd 3.6


bisherige dslbandbereite (bei arcor):
1,5MBit downstream
256kBit upstream

sowohl am server als auch im netzwerk war die internetverbindung bis zur maximalen bandbreite nutzbar (zb downstream 170kbyte/sek)

jetzt habe ich den anbieter gewechselt (zu mnet) und auch gleich ein update der bandbreite auf 6mbit downstream und 512kbit upstream.

die neuen zugangsdaten im configfile angepasst (ppp.conf) und in der pf.conf (die größe der queue altq ua. zur priorisierung der ACK pakete auf 450kBit angepasst, sollte 4:5 des theoretisch maximalen wertes sein.



testlauf:
upstream nur ca 40kByte/sek und downstream gerademal 190/sek bis 230kbyte/sek. gemessen bei unterschiedlichen servern 2 tage lang zu unterschiedlichen tages- und nachtzeiten.

gegentest:
mit meinem freebsd notebook habe ich den test auch gemacht (und dort das modem direkt angeschlossen - sieha da - die vollen 6mbit downstream und 512kbit upstream (abzüglich ein paar prozent protokolloverhead) verfügbar. das ganze wieder an den openbsdrouter angeschlossen - nix mehr - gleiches problem und gleiche werte wie vorher.

fazit: scheint also an der configuration zu liegen.

mittlerweile habe ich auch die größe der queue in pf.conf auf 8196mbit vergrößert, sowie in der pf.conf ein "pass all quick" zu debugzwecken eingestellt (und danach das configfile neu einlesen lassen) hat alles nicht viel gebracht. (maximal 230kbyte/sek downstream, statt der moeglichen > 700kbyte/sek)

die messungen habe ich auch wieder auf verschiedenen servern durchgeführt unteranderem auf einem sehr schnellen von mnet selbst, bei dem ich mit dem notebook steht die 6mbit bekommen habe. nur bei meinem openbsdrouter geht halt nix...

nach einigem surfen habe ich von performance problemen bei aelteren openbsdversionen auf kleinen kisten p1 166mhz oder 486 mit wenig ram usw gelesen, aber bei mir leigt die load bei maximal 0.3 - also kein problem.


unten findet ihr den inhalt der folgenden configfiles:
1. pf.conf
2. ppp.conf
3. ppp.linkup

ich wäre echt froh, wenn juemand nen tip haette, ich suche, lese und robiere bereits seit 2 tagen... vergeblich


vielen dank,
gruß siptec




****************************
pf.conf
****************************

# $OpenBSD: pf.conf,v 1.28 2004/04/29 21:03:09 frantzen Exp $
#
# See pf.conf(5) and /usr/share/pf for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.


### variablen ###

Ext = "tun0"
Int = "rl0"
IntNet = "192.168.0.0/24"
RouterIP = "192.168.0.1"
Loop = "lo0"

table <NoRoute> {127.0.1/8, 172.16.0.0/12, !$IntNet, 10.0.0.0/8, 255.255.255.255/32 }

InServicesTCP = "{ ssh, ftp, auth, http }"

### options ###
set loginterface $Ext
set optimization aggressive

scrub on $Ext all fragment reassemble random-id


### nat and forward ###
altq on $Ext priq bandwidth 8192Kb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default)


nat on $Ext from $IntNet to any -> $Ext static-port


rdr-anchor redirect

### filter ###

#for debugging
#pass quick all

block on $Ext
block return log on $Ext
block quick inet6

pass quick on $Loop

block in log quick on $Ext inet from <NoRoute> to any
block in log quick on $Ext inet from any to <NoRoute>

pass in quick on $Ext inet proto icmp all icmp-type 8 code 0 keep state

pass in quick on $Ext inet proto tcp from any to any port $InServicesTCP flags S/SAFR keep state label ServicesTCP

anchor passin

pass out quick on $Ext keep state queue (q_def,q_pri)






****************************************
ppp.conf
****************************************
#
pppoe:
set device "!/usr/sbin/pppoe -i dc0"
set mtu max 1454
set mru max 1454
set speed sync
disable acfcomp protocomp
set login
set timeout 0
set authname "XXXXXXXX@mdsl.mnet-online.de"
set authkey XXXXXXXX
add! default HISADDR
enable dns
enable mssfixup
disable acfcomp protocomp
set crtscts off
enable lqr
set lqrperiod 5
set dial
deny acfcomp




************************************
ppp.linkup
************************************
MYADDR:
! sh -c "/sbin/ifconfig pflog0 up"
! sh -c "/sbin/pflogd"
! sh -c "/sbin/pfctl -e -F all -f /etc/pf.conf"





************************************
ifconfig -a liefert folgendes (die 10MBit der DslModemkarte sollten ewigentlich kein problem sein
************************************
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:30:bd:70:66:08
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
inet6 fe80::230:bdff:fe70:6608%rl0 prefixlen 64 scopeid 0x1
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:f8:7b:21:c9
media: Ethernet 10baseT
status: active
inet6 fe80::200:f8ff:fe7b:21c9%dc0 prefixlen 64 scopeid 0x2
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33224
pfsync0: flags=0<> mtu 2020
enc0: flags=0<> mtu 1536
tun0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1454
inet 82.135.81.XXX --> 82.135.81.1 netmask 0xffffffff



nochmals danke fuer eure muehen.
 
Hast du schon Paketverluste ausgeschlossen? Das sollte mit netstat herauszufinden sein.
 
danke fuer die erste schnelle antwort!

ja, verlust liegt bei 0 bzw 54 (habe parallel 10mbyte testfile runtergeladen)
ich denke das ist fast nix - oder?

btw: bei dem download soeben lag die geschwindigkeit bei gerademal 124kbyte/sek

$ netstat -bdnI dc0
Name Mtu Network Address Ibytes Obytes Drop
dc0 1500 <Link> 00:00:f8:7b:21:c9 126503788 9789588 0
dc0 1500 fe80::%dc0/ fe80::200:f8ff:fe 126503788 9789588 0

netstat -bdnI tun0
Name Mtu Network Address Ibytes Obytes Drop
tun0 1454 <Link> 125306937 7537928 54
tun0 1454 82.135.81.XXX 82.135.81.251 125306937 7537928 54


gruß martin
 
Bist Du Dir sicher, daß Deine Hardware ok ist? Interrupt-Storm vielleicht?

Ansonsten fällt mir dazu ein, daß altq (bzw. Bandbreitenmanagement / Priorisierung) und tun nicht miteinander wollen (Begründung aus der ML war, daß die Pakete zum tun-Device den Kern verlassen müssen und dabei ihre Paket-Tags verlieren und somit später im Kern nicht sauber in die Queues eingeordnet werden können).

Hast Du mal mpd (statt ppp) probiert? Setzt auf Netgraph auf und sollte damit auch mit altq zusammenarbeiten (ich hoffe, das gibt's auch unter oBSD).
 
hi

nimm mal zum test die setting MRU und mtu aus der ppp.conf raus
die erscheinen mir nicht korrekt.

( normalerweise sollte mtu und mru von deiner gegenseite gesetzt werden )

desweiteren solltest du altq nut fuer die uplolad part nutzen ( 512kbit? )

von daher ist da auch anpassungs bedarf.

ggf fahr mal das logging vom ppp auf debung
ich denke mal das du dort den fehler suchen musst.


holger
 
vielen dank erstmal fuer eure antworten. dann werde ich mir die von euch noch genannten dinge einmal ansehen. ich melde mich dann wieder.

gruß siptec
 
wenn ich das richtig sehe ist die pf.conf für altq nur für upload angepasst, siehe
das die antwort pakete priorisiert rausgehen und damit den download speed
nicht runterdrücken können. den wert von 8192 must du dem upload anpassen.

die mtu sieht bissel wenig aus, lag bei meinen bisherigen anschlüssen immer bei
1492, ein falscher mtu wert kann die BW auch sehr reduzieren

ich selber hatte erst letztes wochenende große probleme in dieser richtung, bei
mir wars letzendlich der userland ppp (8), dann habe ich kernel pppoe (4) benutzt
und siehe volle bandbreite, bei einem wrap(266 mhz)

das könnte man ja mal zum debuggen und ausgrenzen testen
 
also wenn ich es richtig sehe, benutzt du realtek netzwerkkarten - die habe mich damals wegen genau dem gleichen problem fast zur verzweiflung gebracht.
nachdem ich die karten gengen gigabit-intel karten getauscht habe, ging da auch die volle bandbreite durch.
der rl - treiber bzw. der chipsatz sind wol etwas "suboptimal"
 
Laut Theo sind die Gigabit Karten von Realtek im gegensatz zu den anderen Realtek Modellen ganz anständig. Man kann also wie bei Intel zugreifen.
 
In die Hardware-Kerbe wollte ich auch erst schlagen (rl0 und dc0, Not gegen Elend), aber selbst die schaffen normalerweise 10MBit (Tu dir trotzdem den Gefallen und hole dir 2 Marken-NICs auf ebay oder vom Wertstoffhof!)

pf solltest du zum Testen *KOMPLETT* abstellen, die MTU Geschichten erstmal auf 'default' lassen und nicht nur die 'load' betrachten (das ist ein Wert fuer Userland) sondern die exakte Auslastung des System (systat, vmstat, etc.)

Schreibe auch bitte die netstat-Werte von allen drei Interfaces (rl, tun, dc) hier rein, nicht nur die Haelfte :)
 
sodele,

vielen dank für die vielen hinweise erstmal.

also:

mtu und mru in ppp.conf deaktiviert, wird durch betreiber jetzt automatisch auf 1492 gesetzt.
pf komplett deaktiviert (somit auch nix mehr mit pro queue und ACK priorisierung usw)

sorry fuer die halbe netstat angaben:
hier der rest:
*******************************************************
netstat -bdni
Name Mtu Network Address Ibytes Obytes Drop
lo0 33224 <Link> 0 0 0
lo0 33224 127/8 127.0.0.1 0 0 0
lo0 33224 ::1/128 ::1 0 0 0
lo0 33224 fe80::%lo0/ fe80::1%lo0 0 0 0
rl0 1500 <Link> 00:30:bd:70:66:08 5175173 177622206 0
rl0 1500 192.168.0/2 192.168.0.1 5175173 177622206 0
rl0 1500 fe80::%rl0/ fe80::230:bdff:fe 5175173 177622206 0
dc0 1500 <Link> 00:00:f8:7b:21:c9 186454929 7103048 0
dc0 1500 fe80::%dc0/ fe80::200:f8ff:fe 186454929 7103048 0
pflog0 33224 <Link> 0 0 0
pfsync0 2020 <Link> 0 0 0
enc0* 1536 <Link> 0 0 0
tun0 1492 <Link> 183699492 4948348 0
tun0 1492 82.135.84.X 82.135.84.X 183699492 4948348 0
**********************************************************

also eigentlich keine drops zu sehen

das dslmodem haengt am dc0 (teil des motherboards)


zur interruptstormfrage sagt vmstat folgendes:

**************************************
$vmstat -iz
interrupt total rate
irq15/pciide0 0 0
irq9/uhci0 41 0
irq10/rl0 213956 112
irq11/isp0 35498 18
irq10/dc0 222680 117
irq11/bktr0 0 0
irq1/pckbc0 963 0
irq7/lpt0 0 0
irq4/pccom0 88 0
irq3/pccom1 0 0
irq6/fdc0 0 0
irq5/wss1 0 0
irq0/clock 190017 100
irq8/rtc 243215 128
Total 906458 477


und ohne parameter
$ vmstat
procs memory page disks traps cpu
r b w avm fre flt re pi po fr sr cd0 sd0 int sys cs us sy id
0 0 0 33080 424368 70 0 0 0 0 0 0 2 470 1686 368 9 5 86
*********************************************************



die aenderungen bisher haben leider keinerlei nennenswerten effekt gehabt.
so, ich werde jetzt mal noch mit den debug / log options von ppp weitersuchen.


gruß siptec
 
mhm, eine fehlermeldung / warning habe ich noch beim ppp.linkup ppp.linkdown gefunden.

pp[26376]: tun0: warning: 0.0.0.0/0: change route failed: errno: No such process.

allerdings kann ich mir nicht erklären, wie die zustande kommt.


gruß siptec
 
Zurück
Oben