ALTQ Probleme mit tun-device

B

bost

Well-Known Member
Hi,

mal ne grundsätzliche Frage: Funktioniert unter 5_STABLE eigentlich ALTQ auf tun-devices zu 100% ??

Ich arbeite mit ALTQ/PF (priq) und DSL6000 und will TCP-acks priorisieren und die Upload-Bandbreite beschränken, damit der Download nicht zu stark leidet wenn man
mal grossere Sachen uploaded. Das übliche also...
Aber irgendwie scheint das mit der Bandbreitenbeschränkung nicht so richtig hinzuhauen. Ich habe 576Kb Upstream-Bandbreite. Nun versuchte ich knapp drunter die Bandbreite zu beschränken (getestet mit 450-550Kb). Aber jedes mal bricht der Download während des Uploads ein.
Normalerweise habe ich so um die 650KB pro Sekunde download.
Ohne Bandbreiteneinschränkung bricht der Download auf 200KB/s ein.
Aber selbst wenn ich die Bandbreite auf 350Kb (Also fast 50%!) Upstream beschränke, bricht der Download trotzdem auf ca. 450KB/s ein.
Das darf doch eigentlich bei so wenig Upload nicht so stark (eigentlich gar nicht!) einbrechen.

Hat da jemand ähnliche Erfahrung?

MPD habe ich auch schon probiert, aber ng0 Devices haben leider kein ALTQ-Support. :(


Gruss,
Bost
 
Aha.
Wie es aussieht ist dem Problem auch keiner nachgegangen.
Also Pech gehabt. (state closed)
TCP ACK-Priorisierung und DSL geht also gar nicht mit FreeBSD. Super.

Bost
 
Da alle mit so unglaublich detailierten Berichten um sich werfen, ist dem auch schwerlich abzuhelfen.

Bei Max funktioniert es, und wo soll er anfangen nach Fehlern zu suchen bei "geht ned." Gratuliere, volle Punktzahl.
Mach n eigenen PR auf, verweise auf den von AceX5 genannten, sag dass es bei dir auch nicht geht und gib den Jungs INFOS. Kernel Config, dmesg, pf rules als kleiner Anfang.

Abgesehen davon geht TCP ACK Priorisierung mit FreeBSD bei mir wunderbar. Ich verwende allerdings IPFW/Dummynet. Also hier mal keine haltlosen und faktisch falschen behauptungen in den Raum werfen. Danke.
 
bost schrieb:
TCP ACK-Priorisierung und DSL geht also gar nicht mit FreeBSD. Super.
Zum Vergrößern anklicken....
Ich hatte das gleiche Problem mit pf unter OpenBSD, deswegen habe ich zu hfsc statt priq gegriffen. Seitdem geht auch VoIP problemlos, während Up- und Downstream voll ausgelastet sind. Es ist zwar etwas aufwändiger zu konfigurieren, dafür hat man wesentlich mehr Kontrolle über die Priorisierung.
 
Azazyel schrieb:
Ich hatte das gleiche Problem mit pf unter OpenBSD, deswegen habe ich zu hfsc statt priq gegriffen. Seitdem geht auch VoIP problemlos, während Up- und Downstream voll ausgelastet sind. Es ist zwar etwas aufwändiger zu konfigurieren, dafür hat man wesentlich mehr Kontrolle über die Priorisierung.
Zum Vergrößern anklicken....

kannst du mal die config dazu posten? ich hatte vor einiger zeit, unter netbsd allerdings, mit pf+altq rumgespielt mit den regeln von http://www.benzedrine.cx/ackpri.html.

das problem war glaube ich, dass die queue auf einem interface fuer _jeden_ traffic galt, nicht nur den, den man mit pass [...] queue direkt dorthin schiebt. d.h. dass ich effektiv eine queue auf einem interface hatte, welche fuer up _und_ down galt, was natuerlich kaese ist. funktioniert altq bei pf wirklich so, dass jeder traffic, der nicht in eine andere queue geschoben wird, in der default-queue landet? kann ich mir irgendwie nicht vorstellen.
 
Elessar schrieb:
Bei Max funktioniert es, und wo soll er anfangen nach Fehlern zu suchen bei "geht ned." Gratuliere, volle Punktzahl.
Mach n eigenen PR auf, verweise auf den von AceX5 genannten, sag dass es bei dir auch nicht geht und gib den Jungs INFOS. Kernel Config, dmesg, pf rules als kleiner Anfang.
Zum Vergrößern anklicken....

Das hatte ich auch vor, nur wollte ich erstmal sehen wie hier die Resonanz auf das Problem ist.

Übrigens: Wie man ein PR macht ist keine Neuigkeit.

Bost
 
also ich hab bei meiner DSL6000 leitung mal getestet wegen up/downstream

und ich hab mit voller bandbreite gezogen und dann mit ca. 40-60k/s hochgeladen

und ich habe keinen Einbruch gehabt...
ich hab auch von anfang an mehr als die DSL6000 geschwindigkeit (bis zu 900kb/s und mehr teilweise) gehabt nur upstream krieg ich mehr als 60k/s nich hin..

ich nutz das ganze unter FreeBSD 6.0 snap-005 mit PF und altQ und wie schon gesagt, ich seh da kein problem, und wenn die pf.conf nich gepostet wird kann man definitiv nich helfen... (;

aber das hsfc interessiert mich auch .. mal näher anschauen
 
TCM schrieb:
kannst du mal die config dazu posten? ich hatte vor einiger zeit, unter netbsd allerdings, mit pf+altq rumgespielt mit den regeln von http://www.benzedrine.cx/ackpri.html.
Zum Vergrößern anklicken....

Erläuterung zu HFSC
Jede Menge Beispiele

das problem war glaube ich, dass die queue auf einem interface fuer _jeden_ traffic galt, nicht nur den, den man mit pass [...] queue direkt dorthin schiebt. d.h. dass ich effektiv eine queue auf einem interface hatte, welche fuer up _und_ down galt, was natuerlich kaese ist.
Zum Vergrößern anklicken....

Die Reihenfolge, in der Pakete eintreffen, kann man natürlich nicht beeinflussen.
Trotzdem ist es sinnvoll, auch "pass in"-Regeln mit einer Queue zu versehen; nachdem pf ein "stateful packet filter" ist, wird in diesem Fall der ausgehende Traffic dieser Verbindung priorisiert.

funktioniert altq bei pf wirklich so, dass jeder traffic, der nicht in eine andere queue geschoben wird, in der default-queue landet? kann ich mir irgendwie nicht vorstellen.
Zum Vergrößern anklicken....

Das ist die einzig sinnvolle Regelung. Das Interface handelt ja nach dem Prinzip "first in, first out".

Beispiel: Parallel läuft Bittorrent und FTP-Upload. TCP-ACK wird priorisiert, Bittorrent-Daten werden zurückgestellt. Für den FTP-Traffic gibt es keine Regel.

Wir betrachten nun den Upload.
Angenommen, es kommen nun Pakete in folgender Reihenfolge ans Interface:
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • Bittorrent-Daten
  • TCP-ACK für Bittorrent

Ohne Filterregeln (es gilt "first in, first out"):
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • Bittorrent-Daten
  • TCP-ACK für Bittorrent

Mit Filterregeln, aber ohne Default-Queue:
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • TCP-ACK für Bittorrent
  • Bittorrent-Daten

Mit Filterregeln und mit Default-Queue:
  • TCP-ACK für Bittorrent
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • FTP-Upload
  • Bittorrent-Daten

Wie man sieht, führt nur die Default-Queue zum eigentlich erwünschten Ergebnis.
 
ChaosKind schrieb:
ich nutz das ganze unter FreeBSD 6.0 snap-005 mit PF und altQ und wie schon gesagt, ich seh da kein problem, und wenn die pf.conf nich gepostet wird kann man definitiv nich helfen... (;
Zum Vergrößern anklicken....

Das ist aber wenigstens mal ein Grund RELENG_6 zu testen.
pf.conf brauch ich nicht posten, die ist optimal - und daran liegt es auch nicht.
Es gibt ja nur mit tunX Probleme.

Ich wollte auch keine Problemlösung, sondern nur hören, ob vielleicht auch bei anderen dieses Problem auftritt. Der Rest ist dann was fürn PR.

Ich denke auch mal, dass man das Problem auch nur erkennt, wenn man es mal
genau mißt und vergleicht. So beim normalen Surfen merkt man den Mißstand sicherlicht nicht sofort.

Gruss,
Bost
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben