WinFuture-Forum.de: Traffic Shaping ohne Angabe der verfügbaren Bandbreite - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Linux
Seite 1 von 1

Traffic Shaping ohne Angabe der verfügbaren Bandbreite


#1 Mitglied ist offline   Sworddragon 

  • Gruppe: aktive Mitglieder
  • Beiträge: 27
  • Beigetreten: 23. November 12
  • Reputation: 0
  • Geschlecht:unbekannt

geschrieben 19. November 2013 - 19:41

Zwar gibt es im Internet viele Scripte, welche Traffic Shaping ermöglichen, allerdings muss man dazu die verfügbare Bandbreite angeben. Allerdings hat das auch Nachteile, vor allem, wenn die Leitung sehr oft schwankt (was bei mir der Fall ist), Drosselungen passieren, etc. Daher suche ich eine generische Lösung, meine erste Anlaufstelle war daher, ob es im Kernel einen Scheduler gibt. Aber erstmal zum Testfall:

So sieht die aktuelle Scheduler-Konfiguration aus:

[email protected]:~# tc -s qdisc ls dev eth0
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 272010 bytes 1294 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0


Damit sehen dann ein paar Pings auf Google so aus, wenn die Leitung anderweitig nicht belastet ist:

[email protected]:~# ping www.google.de -c 5
PING www.google.de (173.194.32.255) 56(84) bytes of data.
64 bytes from ber01s09-in-f31.1e100.net (173.194.32.255): icmp_seq=1 ttl=58 time=40.1 ms
64 bytes from ber01s09-in-f31.1e100.net (173.194.32.255): icmp_seq=2 ttl=58 time=38.9 ms
64 bytes from ber01s09-in-f31.1e100.net (173.194.32.255): icmp_seq=3 ttl=58 time=39.4 ms
64 bytes from ber01s09-in-f31.1e100.net (173.194.32.255): icmp_seq=4 ttl=58 time=39.8 ms
64 bytes from ber01s09-in-f31.1e100.net (173.194.32.255): icmp_seq=5 ttl=58 time=39.5 ms

--- www.google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4019ms
rtt min/avg/max/mdev = 38.936/39.597/40.183/0.412 ms


Mit "dd bs=1M count=50 if=/dev/zero of=/tmp/test.txt" habe ich mir eine Testdatei erstellt, welche ich nun auf einen beliebigen Dateihoster hochlade (in diesem Beispiel http://www.file-upload.net/). Während dieses Vorgangs pinge ich Google nochmal:

[email protected]:~# ping www.google.de -c 5
PING www.google.de (173.194.32.248) 56(84) bytes of data.
64 bytes from ber01s09-in-f24.1e100.net (173.194.32.248): icmp_seq=1 ttl=58 time=178 ms
64 bytes from ber01s09-in-f24.1e100.net (173.194.32.248): icmp_seq=2 ttl=58 time=161 ms
64 bytes from ber01s09-in-f24.1e100.net (173.194.32.248): icmp_seq=3 ttl=58 time=157 ms
64 bytes from ber01s09-in-f24.1e100.net (173.194.32.248): icmp_seq=4 ttl=58 time=152 ms
64 bytes from ber01s09-in-f24.1e100.net (173.194.32.248): icmp_seq=5 ttl=58 time=135 ms

--- www.google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4015ms
rtt min/avg/max/mdev = 135.798/157.174/178.567/13.775 ms


Die Werte sehen ziemlich schlecht aus, daher probiere ich mal den "Stochastic Fairness Queuing" scheduler (SFQ):

[email protected]:~# tc qdisc add dev eth0 root sfq
[email protected]:~# tc -s qdisc ls dev eth0
qdisc sfq 8005: root refcnt 2 limit 127p quantum 1514b depth 127 divisor 1024 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0


Während ich die Datei erneut hochlade pinge ich nochmal Google:

[email protected]:~# ping www.google.de -c 5
PING www.google.de (173.194.32.248) 56(84) bytes of data.
64 bytes from ber01s09-in-f24.1e100.net (173.194.32.248): icmp_seq=1 ttl=58 time=161 ms
64 bytes from ber01s09-in-f24.1e100.net (173.194.32.248): icmp_seq=2 ttl=58 time=157 ms
64 bytes from ber01s09-in-f24.1e100.net (173.194.32.248): icmp_seq=3 ttl=58 time=165 ms
64 bytes from ber01s09-in-f24.1e100.net (173.194.32.248): icmp_seq=4 ttl=58 time=170 ms
64 bytes from ber01s09-in-f24.1e100.net (173.194.32.248): icmp_seq=5 ttl=58 time=96.5 ms

--- www.google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4015ms
rtt min/avg/max/mdev = 96.526/150.309/170.565/27.238 ms


Das sieht kaum besser aus, zumindest sind das nicht die erhofften Ergebnisse.


Daher nun die Frage: Kennt sich jemand besonders gut in diesen Gebiet aus und kann mir sagen, was eventuell falsch ist/wie ich es besser machen kann?

Dieser Beitrag wurde von Sworddragon bearbeitet: 19. November 2013 - 19:44

0

Anzeige



#2 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.782
  • Beigetreten: 20. Juli 07
  • Reputation: 1.109
  • Geschlecht:Männlich
  • Wohnort:Jena

geschrieben 19. November 2013 - 21:14

Und was erhoffst Du Dir? Das ist mir grad nicht ganz klar. :unsure:

Traffic Shaping macht die Verbindung nicht schneller, sondern 'glatter'. Daß die Pings länger dauern, wäre eine zu erwartende Folge des Traffic Shapings - und auch in keiner Form aussagekräftig. Dazu müßtest Du schon während des Uploads auf andere Websites zugreifen oder sonst "normale" Netzdienste nutzen.


Die Angabe der Leitungskapazität dient übrigens insbesondere der Optimierung, denn wenn man sie weglassen und mehr oder weniger automatisch (und dynamisch) bestimmen lassen würde (soweit das möglich ist) würde das ja wieder den Scheduler durcheinanderbringen.


Bin leider grad mit der Implementierung in Linux nicht so vertraut, aber wenn ich mir den von Dir geposteten Auszug mal anschau, sieht das auch ein wenig so aus, als wäre der Scheduler auch an konkrete Netzwerkkarten gebunden. In diesem Fall würde Dir das nur dann etwas bringen, wenn Du mehr als nur eine Netzwerkkarte im Rechner hättest und via Traffic Shaping dann diese oder jene Leitung für diese oder jenen Type-of-Service bevorzugt behandeln würdest.

Alles andere müßte man ohnehin konfigurieren. Woher sollte der Planer sonst wissen, was er zu bevorzugen hat und was zurückgestellt werden kann?
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#3 Mitglied ist offline   Sworddragon 

  • Gruppe: aktive Mitglieder
  • Beiträge: 27
  • Beigetreten: 23. November 12
  • Reputation: 0
  • Geschlecht:unbekannt

geschrieben 19. November 2013 - 21:42

Beitrag anzeigenZitat (RalphS: 19. November 2013 - 21:14)

Und was erhoffst Du Dir? Das ist mir grad nicht ganz klar. :unsure:


Geringere Latenz im Testfall und produktiv bezogen keine erheblichen Verzögerungen beim Surfen sobald ich den Upload ausschöpfe.


Beitrag anzeigenZitat (RalphS: 19. November 2013 - 21:14)

Traffic Shaping macht die Verbindung nicht schneller, sondern 'glatter'.


Das Traffic Shaping eine Verwaltung/Priorisierung auf Netzwerkebene ist und nicht die maximale Geschwindigkeit erhöht (zumindest aber die Durchschnittsgeschwindigkeit bei Engpässen) weiß ich.


Beitrag anzeigenZitat (RalphS: 19. November 2013 - 21:14)

Daß die Pings länger dauern, wäre eine zu erwartende Folge des Traffic Shapings - und auch in keiner Form aussagekräftig.


Der sfq-Scheduler versucht alle Pakete möglichst gleich zu priorisieren, während pfifo_fast ähnlich wie ein FIFO funktioniert. Bei sfq würden also die Pings theoretisch schneller rauskommen.

Soche Pingtests habe ich auch vor einigen Jahren mit Windows XP und cFosSpeed gemacht - mit dem gewünschten Erfolg.


Beitrag anzeigenZitat (RalphS: 19. November 2013 - 21:14)

Dazu müßtest Du schon während des Uploads auf andere Websites zugreifen oder sonst "normale" Netzdienste nutzen.


Wie oben schon angedeutet habe ich das auch gemacht, aber ein Testfall lässt sich leichter nachvollziehen.


Beitrag anzeigenZitat (RalphS: 19. November 2013 - 21:14)

Die Angabe der Leitungskapazität dient übrigens insbesondere der Optimierung, denn wenn man sie weglassen und mehr oder weniger automatisch (und dynamisch) bestimmen lassen würde (soweit das möglich ist) würde das ja wieder den Scheduler durcheinanderbringen.


Der Scheduler priorisiert auf Paketebene, da ist es egal, wie schnell die Leitung ist.


Falls ich mich doch irgendwo geirrt haben sollte, korrigiert mich einfach :)


Edit: Da ich noch Windows XP auf einer anderen Partition installiert hatte, habe ich das mal dort getestet. So sieht der Ping auf Google aus, wenn nichts hochgeladen wird:

J:\>ping www.google.de

Ping www.google.de [173.194.113.152] mit 32 Bytes Daten:

Antwort von 173.194.113.152: Bytes=32 Zeit=34ms TTL=58
Antwort von 173.194.113.152: Bytes=32 Zeit=33ms TTL=58
Antwort von 173.194.113.152: Bytes=32 Zeit=33ms TTL=58
Antwort von 173.194.113.152: Bytes=32 Zeit=34ms TTL=58

Ping-Statistik für 173.194.113.152:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 33ms, Maximum = 34ms, Mittelwert = 33ms


Bei einen gleichzeitigen Upload sieht es dann so aus:

J:\>ping www.google.de

Ping www.google.de [173.194.113.159] mit 32 Bytes Daten:

Antwort von 173.194.113.159: Bytes=32 Zeit=118ms TTL=58
Antwort von 173.194.113.159: Bytes=32 Zeit=151ms TTL=58
Antwort von 173.194.113.159: Bytes=32 Zeit=121ms TTL=58
Antwort von 173.194.113.159: Bytes=32 Zeit=167ms TTL=58

Ping-Statistik für 173.194.113.159:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 118ms, Maximum = 167ms, Mittelwert = 139ms


Bisher gibt es keinen Unterschied zu Linux. Nach dem Installieren von cFosSpeed 9.04 sieht bei einen Upload der Ping dann so aus, wenn cFosSpeed aktiv läuft:

J:\>ping www.google.de

Ping www.google.de [173.194.113.151] mit 32 Bytes Daten:

Antwort von 173.194.113.151: Bytes=32 Zeit=53ms TTL=58
Antwort von 173.194.113.151: Bytes=32 Zeit=57ms TTL=58
Antwort von 173.194.113.151: Bytes=32 Zeit=57ms TTL=58
Antwort von 173.194.113.151: Bytes=32 Zeit=49ms TTL=58

Ping-Statistik für 173.194.113.151:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 49ms, Maximum = 57ms, Mittelwert = 54ms


Das sieht gut aus, so hätte ich es auch gerne unter Linux. Wenn cFosSpeed nicht aktiv läuft (Tray und Systemdienst deaktiviert) sieht es dann so aus:

J:\>ping www.google.de

Ping www.google.de [173.194.113.151] mit 32 Bytes Daten:

Antwort von 173.194.113.151: Bytes=32 Zeit=41ms TTL=58
Antwort von 173.194.113.151: Bytes=32 Zeit=51ms TTL=58
Antwort von 173.194.113.151: Bytes=32 Zeit=65ms TTL=58
Antwort von 173.194.113.151: Bytes=32 Zeit=54ms TTL=58

Ping-Statistik für 173.194.113.151:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 41ms, Maximum = 65ms, Mittelwert = 52ms


Anscheinend muss cFosSpeed nichtmal aktiv laufen, sondern scheint ähnlich wie ein Treiber zu funktionieren. Nachdem ich cFosSpeed deinstalliert habe sieht es dann so aus:

J:\>ping www.google.de

Ping www.google.de [173.194.113.152] mit 32 Bytes Daten:

Antwort von 173.194.113.152: Bytes=32 Zeit=99ms TTL=58
Antwort von 173.194.113.152: Bytes=32 Zeit=158ms TTL=58
Antwort von 173.194.113.152: Bytes=32 Zeit=127ms TTL=58
Antwort von 173.194.113.152: Bytes=32 Zeit=166ms TTL=58

Ping-Statistik für 173.194.113.152:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 99ms, Maximum = 166ms, Mittelwert = 137ms


Wie erwartet kehrt das alte Verhalten zurück.

Dieser Beitrag wurde von Sworddragon bearbeitet: 20. November 2013 - 15:16

0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0