WAN Bandbreiten Messung

Hi,

das was jetzt kommt hat alles letztlich mit diesem Thread hier zu tun. Nur dachte ich es macht vllt Sinn das in einem neuen Thread zu posten.

Ich versuche in einer Testumgebung mittels einer Linux VM Charakteristika einer bestehenden WAN Strecke nachzuempfinden. Die Linux VM soll also im Lab als Router agieren und traffic shaping so betreiben, dass die Eigenschaften der Verbindung der WAN Verbindung um die es geht sehr nahe kommen.

Ne ganze Menge Eigenschaften kann man ja auch den Ergebnissen von Ping rauslesen:

Code:
--- 192.168.1.10 ping statistics ---
1000 packets transmitted, 998 received, 0% packet loss, time 200408ms
rtt min/avg/max/mdev = 103.983/112.764/232.996/17.065 ms, pipe 2

Nun geht es aber um die Bandbreite. Dazu habe ich mit iperf folgenden Test gemacht:

Server Seite:
Code:
root@kvm01:~# iperf -s

Client Seite:
-f k = format in KBit
-i 20 = 20 Sekunden Pause zwischen periodischen Tests
-m = zeigt TCP maximum segment size an
-u = UDP
-c 192.168.1.10 = verbinde zu 192.186.1.0 (server)
-t 60 = Sende 60 Sekunden lang Daten pro Test

Code:
root@kvm00:~# iperf -f k -i 20 -m -u -c 192.168.1.10 -t 60
------------------------------------------------------------
Client connecting to 192.168.1.10, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   122 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 41809 connected with 192.168.1.10 port 5001
^[      [ ID] Interval       Transfer     Bandwidth
[  3]  0.0-20.0 sec  2525 KBytes  1034 Kbits/sec
[  3] 20.0-40.0 sec  2531 KBytes  1037 Kbits/sec
[  3] 40.0-60.0 sec  2531 KBytes  1037 Kbits/sec
[  3]  0.0-60.0 sec  7588 KBytes  1036 Kbits/sec
[  3] Sent 5351 datagrams
read failed: Connection refused
[  3] WARNING: did not receive ack of last datagram after 2 tries.
root@kvm00:~# iperf -f k -i 20 -m -c 192.168.1.10 -t 60
------------------------------------------------------------
Client connecting to 192.168.1.10, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 60386 connected with 192.168.1.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-20.0 sec  9424 KBytes  3860 Kbits/sec
[  3] 20.0-40.0 sec  8936 KBytes  3660 Kbits/sec
[  3] 40.0-60.0 sec  9392 KBytes  3847 Kbits/sec
[  3]  0.0-60.5 sec  27760 KBytes  3759 Kbits/sec
[  3] MSS size 1353 bytes (MTU 1393 bytes, unknown interface)
root@kvm00:~#

Ich mach den Test also 2 Mal, mit nahezu identischen Parametern. Der Unterschied ist einem UDP und einmal TCP. Mit TCP scheine ich einer deutlich höhere Bandbreite zu bekommen, und deswegen überhaupt dieser Thread: Macht das nicht irgendwie wenig Sinn? Nachdem UDP ja das Protokol mit dem deutlich geringeren Overhead ist, hätte ich hier mehr Durchsatz erwartet als bei TCP!?!

Grüße
serow
 
Hi nochmal, eins sollte man vllt noch erwähnen: Zwischen den beiden Standorten, also letztlich den beiden Servern mit denen ich die Tests macht, steht eine Linux Kiste, die als DSL Router agiert und zur anderen Seite eine OpenVPN Verbindung aufmacht:

Client:
Code:
proto udp
remote *************
dev tun-client
comp-lzo
keepalive 10 30
persist-tun
ifconfig 10.8.0.2 10.8.0.1
secret praxis.static.key
route 192.168.1.0 255.255.255.0

Server:
Code:
proto udp
port 1194
dev tun-server
comp-lzo
keepalive 10 30
persist-tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key
route 192.168.0.0 255.255.255.0

Der VPN Tunnel ist also UDP basiert mit Compression.

Gruesse
serow
 
Das Problem an der Messung ist, dass iperf UDP- und TCP-Pakete unterschiedlich versendet und es desshalb schwierig ist, beide Werte miteinander zu vergleichen. UDP-Pakete werden (afaik!!!) mit einer konstanten Senderate an die unteren Schichten weitergegeben, wohingegen TCP-Pakete meines Wissen immer als komplette Pakete versendet werden, wodurch die Flusskontrolle zu greifen beginnt. Nun hast du zusätzlich unterschiedliche Puffergrößen (/proc/sys/net/ipv4/tcp_{wmem,rmem,mem} vs. /proc/sys/net/ipv4/udp_mem), wodurch das Senden und Empfangen bzw. Weitergeben an die darüber (empfangen) / darunter (senden) gelegenen Ebenen (OSI-Modell!) "verzögert" bzw. mit anderer Priorität durchgeführt wird. Irgendwo hatte ich mal gelesen, dass UDP Pakete für Latenzabhängige Verbindungen optimiert wurde, TCP dagegen für Geschwindigkeitsabhängige. Leider finde ich gerade keine gute Quelle mehr dazu...
 
Zurück
Oben