DSL: OpenBSD deutlich langsamer als andere OS

nihonto

Well-Known Member
Hiho,

ich hab' den ISP gewechselt und jetzt 'ne Flat bis 16Mbit. Was mich wundert: Wenn ich unter OpenBSD 4.3 einen Speedtest bei www.wieistmeineip.de mache, komme ich grade mal auf etwas mehr als 3 Mbit:eek:!

Unter Debian und WinXP sind's immerhin 10 Mbit:cool:.

Ist eine Flat von Hansenet (Alice Light). Hinter der TAE-Dose hängt erstmal ein Sphairon Turbolink IAD (=DSL-Modem). Dann kommt eine Fritzbox 7050 als Router und dann mein Laptop. Pf-Firewall nutze ich nicht.

Oder kommen die Speedtests im Netz nicht mit OpenBSD klar?

Woran könnte das liegen?
 
Oooookay, habe mir jetzt mal man 4 pppoe durchgelesen.

Was mich ehrlich gestanden etwas wundert: Wieso brauche ich das jetzt plötzlich?

Und wieso muss ich das auf dem Laptop einrichten, wo ich doch schon der Fritzbox klar gemacht habe, dass sie sich per pppoe einwählen soll?

Und noch was: In man 4 pppoe steht

A typical /etc/hostname.pppoe0 file looks like this:

inet 0.0.0.0 255.255.255.255 NONE \
pppoedev ne0 authproto pap \
authname 'testcaller' authkey 'donttell' up
dest 0.0.0.1
!/sbin/route add default -ifp pppoe0 0.0.0.1

Soll ich da unter authname und authkey Benutzername und Passwort für den DSL-Zugang eingeben? Hab' ich doch schon im Router?!

Sorry, aber ich versteh' nicht, warum das jetzt plötzlich nötig sein soll:confused:

@ condor:

Du schreibst:

Und beim Ändern von tun0 auf pppoe0 doch bitte die pf Regeln bedenken [...]

Woher soll plötzlich tun0 kommen? Ich hab' 'ne Broadcom-Nic für's LAN und 'ne Intel-Nic für's WLAN im Laptop. Und pf-Regeln gibt's bei mir keine - mir reicht die Firewall im Router.

Nochmal sorry, aber ich seh' im Moment nur noch Fragezeichen:zitter:
 
Wenn du nicht direkt mit dem Gerät ins Netz gehst, brauchst du es natürlich nicht.

Dann liegt das Problem irgendwo anders. Das war aus deinem ersten Post aber nicht zu ersehen.
 
@ condor:

Du schreibst:



Woher soll plötzlich tun0 kommen? Ich hab' 'ne Broadcom-Nic für's LAN und 'ne Intel-Nic für's WLAN im Laptop. Und pf-Regeln gibt's bei mir keine - mir reicht die Firewall im Router.

Nochmal sorry, aber ich seh' im Moment nur noch Fragezeichen:zitter:

Das war weniger ein Hinweis für dich, als ein allgemeiner Kommentar über meine Schussligkeit :[
(Du hast ja oben schon geschrieben du nutzt kein pf)
 
Wenn du nicht direkt mit dem Gerät ins Netz gehst, brauchst du es natürlich nicht.

Dann liegt das Problem irgendwo anders. Das war aus deinem ersten Post aber nicht zu ersehen.

*räusper* nix für ungut,aber wie hätte ich es noch deutlicher formulieren können;):

Hinter der TAE-Dose hängt erstmal ein Sphairon Turbolink IAD (=DSL-Modem). Dann kommt eine Fritzbox 7050 als Router und dann mein Laptop.

Als schematische Darstellung wird's evtl. klarer:

TAE-Dose ---> DSL-Modem ---> Fritzbox-Router ---> Laptop (per dhcp verbunden)

Wie bereits gesagt: Download unter OpenBSD ~3 Mbit, unter Debian und WinXP ~10Mbit.

Me = :confused:
 
Also dieses Speedtests sind, mehr oder weniger, schmarn - das sollte inzwischen überall hingedrungen sein, vermutlich ist das eher ein Problem des Browsers mit OpenBSD, als tatsächlich die Verbindung ;)

Versuch doch mal von einem bekannt-schnellen-server ein paar isos zu ziehen, oder wenns t-online ist, von einem der t-online server etwas zu kopieren.
 
seltsam.

ich habe hier

Code:
Download-Geschwindigkeit: [o] 10.955 kbit/s (1.369 kByte/s)
Upload-Geschwindigkeit: [++] 1.147 kbit/s (143 kByte/s)

und bin sogar ueber zwei openbsd-kisten mit dem internet verbunden :D

desktop -> soekris -> dsl-modem
 
Oh, was mir auch noch auffält:

1. Wird die verbindung von anderen PCs mitgenutzt?

2. Direkt per Kabel oder WLAN?
 
3. Was für eine Netzwerkkarte nutzt du? Es gibt ein paar netzwerkchips die nicht "so" sauber sind, und unter dem ein oder anderen Betriebsystem (b.z.w. unter Windows auch mal mit bestimmten Treiber Versionen) mal nicht, mal gut, mal schlecht funktionieren - insbesondere "Realtek"-100mbit-karten sind dafür bekannt

4. Dann solltest du wirklich mal die "reine" downloadgeschwindkeitkeit ausprobieren, z.b. mit ftp oder wget oder so - bei mir hat der Firefox u.a. in Verbindung mit Javascript teilweise gewaltige Performance-Probleme - das hat allerdings nichts mit dem "Down- oder Upload" der Internetverbindung zu tun
 
Hi Zed,

war ein bisschen beschäftigt, daher erst jetzt 'ne Antwort;).

ad 3) Ich hab' 'ne Broadcom-Nic für's LAN (bge0; siehe man-page). Bin grade nicht zu Hause, daher kann ich auch nicht den genauer Typ angeben.
Das Realteks gerne mal Probleme machen, hab' ich schon öfter gehört. Hab' selber aber nie Ärger mit den Teilen gehabt (vermutlich Glück gehabt).

ad 4) Du schreibst:
Dann solltest du wirklich mal die "reine" downloadgeschwindkeitkeit ausprobieren, z.b. mit ftp oder wget oder so ...
Aber wie kann ich da die Geschwindigkeit messen? Ich könnte höchstens die Downl.-Zeit stoppen, die gleiche Datei (oder eine ISO) nochmal unter XP oder Debian ziehen und dann die Zeiten vergleichen, oder? Denn bei 'nem reinen Dateidownload bekomme ich doch außer 'nem Fortschrittsbalken nix angezeigt.

Ach und nochwas: Da ich mich offenbar bei dem Update von 4.2 auf 4.3 ein bisschen ungeschickt angestellt habe, musste ich das System nochmal neu installieren. Insofern hatte ich auch eine ganz gute Vergleichsmöglichkeit alt <-> neu. Im Ergebnis hat sich aber nix geändert.
 
Als schematische Darstellung wird's evtl. klarer:

TAE-Dose ---> DSL-Modem ---> Fritzbox-Router ---> Laptop (per dhcp verbunden)
Du hast den Splitter vergessen :D

nihonto schrieb:
Aber wie kann ich da die Geschwindigkeit messen? Ich könnte höchstens die Downl.-Zeit stoppen, die gleiche Datei (oder eine ISO) nochmal unter XP oder Debian ziehen und dann die Zeiten vergleichen, oder? Denn bei 'nem reinen Dateidownload bekomme ich doch außer 'nem Fortschrittsbalken nix angezeigt.
ftp zeigt eigentlich nach Abschluss eine durchschnittliche Download-Rate an. Außerdem kannst Du die Downloads natürlich mit time stoppen und Dir die Rate anhand der Dateigröße selbst berechnen.
 
Hmmm, irgendwie komm' ich nicht so recht weiter. Aber anscheinend stimmen auch die für DSL nicht ganz unwichtigen Werte für MTU und TCP Receive-Window nicht:

1. ifconfig meint zu meiner LAN-Nic:

/home/nihonto $ ifconfig -m bge0
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:11:2f:a6:21:f1
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
supported media:
media 10baseT
media 10baseT mediaopt full-duplex
media 100baseTX
media 100baseTX mediaopt full-duplex
media 1000baseT
media 1000baseT mediaopt full-duplex
media autoselect
inet6 fe80::211:2fff:fea6:21f1%bge0 prefixlen 64 scopeid 0x1
inet 192.168.x.x netmask 0xffffff00 broadcast 192.168.x.x

Und "mtu 1500" dürfte doch nicht ganz stimmen, oder? Sollte da nicht 1492 angegeben werden? Kann man das irgendwo fix einstellen? Mit ifconfig geht's ja immer nur für die aktuelle Session.

2. Das TCP Receive-Window (RWIN). Da meint der TCP/IP Analyzer (speedguide.net), dass das RWIN bei 16384 liege. Das RWIN soll ja immer ein Vielfaches der MSS sein. Die MSS liegt bei 1452 und 16384 ist leider kein Vielfaches davon. Kann man das irgendwo noch händisch nachjustieren?
 
Schau dir mal deine /etc/hostname.bge0 an. Da kannst du alles eingeben, was nach dem Neustart erhalten bleiben soll.

edit: Auf der LAN-Seite ist dein MTU übrigens uninteressant. Kannst du auf default stehen lassen.
 
Zuletzt bearbeitet:
Heureka - es tut sich was:D!

Habe gestern Abend noch ein bisschen Google gequält und bin darauf gestoßen, dass man den Parameter

net.inet.tcp.recvspace

in der /etc/sysctl.conf variieren kann. So wie's aussieht entspricht dieser Parameter dem TCP Receive Window, das bei mir bislang auf 16384 stand - viel zu niedrig für eine 16 Mbit-Leitung. Ich habe da jetzt mal ein Vielfaches des MSS-Wertes von 1452 eingegeben - und der Download liegt plötzlich bei rund 10 Mbit/s:cool:!!!
 
Soooo, sieht so aus, als ob das Problem gelöst sei:cool:!

Habe jetzt mal die folgenden Einträge in die /etc/sysctl.conf genommen:

net.inet.tcp.mssdflt=1452
net.inet.tcp.recvspace=255552
net.inet.tcp.sendspace=127776
Basiert ehrlich gestanden auf reinem Rumprobieren - aber scheint zu funktionieren:).
Wem da noch was auffällt (Fehler, Verbesserungen), ist herzlich gebeten, es hier anzumerken;).

Dann hab' ich heute morgen mal die Hotline angerufen und mein Profil raufsetzen lassen. Und jetzt klappt's auch mit dem Internet: 15 Mbit/s Download mit OpenBSD, Debian und XP:D
 
Nur mal kurz für mich zum Verständnis: war das nun ein spezifisches Problem, was nihonto mit seinem Rechner/seiner DSL Verbindung hatte oder wird man solche Probleme immer haben, wenn man OpenBSD einsetzt?
 
ich denke mal, dass das stark von der hardware abhängt und wohl auch von der gegenstelle. es gibt hier noch einen anderen thread, der eine vdsl-einrichtung beschreibt und dort wird auch der recvspace auch hochgesetzt. die manpage sagt dazu:

tcp.recvspace
Returns the default TCP receive buffer size.

und da muss eben auch die netzwerkkarte mitspielen und ansonsten genügend pakete verarbeiten können, damit die geschwindigkeit hoch bleibt (da die mtu kleiner wird, kommt es auf die paketanzahl an, die die karte verarbeiten kann, und nicht auf die linkgeschwindigkeit)
 
Meine unmaßgebliche Nicht-Expertenmeinung: Scheint von der Bandbreite abzuhängen.

Denn:

a) Handelt es sich in meinem Fall um ein nigelnagelneu aufgesetztes OpenBSD 4.3 ohne irgendwelche Individual-Frickelei (naja, nach der Aktion jetzt schon:D)

b) Hatte ich diese Probleme nicht, solange ich meine alte 2Mbit-Flat bei 1&1 hatte. Oder präziser ausgedrückt: Es ist mir da nicht aufgefallen!

Soweit ich es beurteilen kann, ist das TCP Receive-Window für höhere Bandbreiten 'n büschen zu klein voreingestellt.

Weitere Meinungen dazu von Leuten die Ahnung haben, würden mich aber auch interessieren!
 
Soweit ich es beurteilen kann, ist das TCP Receive-Window für höhere Bandbreiten 'n büschen zu klein voreingestellt.

wie ich bereits schrieb, kommt es dabei auf die paketgröße an, die hier unterhalb der MTU liegt. weil für 100Mbit muss man auch nicht unbedingt an den werten drehen, damit die karten das auch leisten ;)
 
Zurück
Oben