Bandbreiten Analyse Dezember 2012

Aus Opennet
Wechseln zu: Navigation, Suche


Inhaltsverzeichnis

Bandbreitenmessung 28.12.2012

Ziel

  • Analyse der potentiellen Performance-Verluste aufgrund der virtuellen Bridge in Server/tamago anhand von einfachen iperf-Messungen mit oder ohne Tunnel

Setup

  • iperf läuft als Server auf titan:
 iperf -s
    • Ports temporär öffnen:
  iptables -I external_in -p udp --dport 5001 -j RETURN
  iptables -I external_in -p tcp --dport 5001 -j RETURN
    • Regeln anschließend wieder entfernen:
  iptables -D external_in -p udp --dport 5001 -j RETURN
  iptables -D external_in -p tcp --dport 5001 -j RETURN
  • direkten Link ins Internet (ohne VPN) für spezifische IP ermöglichen:
    • auf titan zulassen:
  iptables -I FORWARD -d 83.169.20.153 -j ACCEPT
      • am Ende wieder aufräumen:
  iptables -D FORWARD -d 83.169.20.153 -j ACCEPT
    • direktes Routing AP kurzfristig aktivieren (auf dem AP!):
  ip route add 83.169.20.153 via 192.168.0.254
    • direktes Routing hinterher deaktivieren (auf dem AP!):
  ip route del 83.169.20.153 via 192.168.0.254
  • OpenVPN-Client:
    • auf den verwendeten APs muss ein VPN-Zertifikat konfiguriert werden, um die VPN-Messungen zu ermöglichen

Ergebnisse

Die in der Tabelle aufgeführten Zahlenwerte sind das Ergebnis einfacher oder mehrfacher Durchläufe von iperf -c ZIEL_IP (Messung der Übertragungsgeschwindigkeit in Richtung des Ziels). Die Schwankungen hielten sich üblicherweise im Rahmen von ca. +/- 10%.

Die folgenden Geräte waren an der Messung beteiligt:

Bullet M5
  • AP1.79
  • der Rundstrahler auf dem Philoturm
  • über den Philoturm mit 100 MBit/s an das Rechenzentrum angebunden
  • Prozessor: Atheros MIPS 24KC, 400 MHz (wie Nanostation)
WRT54GL
  • AP1.171
  • ein AP auf der Z10
  • über das Südstadtkrankenhaus mit dem Rechenzentrum verbunden
    • ein besser angebundener WRT war nicht verfügbar
  • auf dem alten WRT (mit White Russian) lief iperf leider nur im Server-Modus (Client: "broken pipe" bei allen Verbindungen)
    • daher waren leider nur pull-Operationen (via iperf-Server oder wget-Download) anstelle der push-Operation (iperf-Client) möglich
  • Prozessor: Broadcom BCM5352, 200 MHz
inez
  • virtualisierter Host
  • Nachbar von titan auf tamago
extern
  • ein VServer von Hosteurope

Die Übertragungswege sind folgende:

direkt
einfaches Routing zu/über titan (muss vorher auf titans Firewall erlaubt werden)
openvpn (plain)
OpenVPN-Tunnel mit cipher = none
openvpn (BF-CBC)
der übliche OpenVPN-Tunnel, den die meisten APs im Opennet verwenden
Gerät direkt openvpn (plain) openvpn (BF-CBC)
Bullet M5 -> titan 94 28 21
Bullet M5 -> extern 15 12 11
titan -> WRT54GL 20  ? 15
extern -> WRT54GL 2,8 2,3 2,3
titan -> extern 95 - -
inez -> extern (Route über titan) 95 - -


Auswertung

  • titan ist mit 100 MBit/s an das Internet angebunden
  • Bandbreite via OpenVPN mit moderner Hardware (Bullet M5):
    • bis titan: 21 MBit/s
    • Internet: 11 MBit/s
  • Verschlüsselung hat geringen Einfluss auf die Bandbreite (0..25%)
    • Bullet war während der Messung überwiegend im Userspace beschäftigt (openvpn?)
      • keine wahrnehmbare Veränderung der Userspace-Aktivität mit oder ohne Verschlüsselung
    • WRT54GL befand sich während der Messung überwiegend im Kernelspace
  • titan verlangsamt weiterzuleitenden Verkehr (direkt, ohne VPN) erheblich
    • Verkehr von Nachbar-Hosts (z.B. inez) im Virtualisierungsserver ist nicht betroffen (ca. 100 MBit/s ins Internet, trotz Umlenkung über titan)
    • Verkehr von benachbartem Opennet-AP (mit 100 MBit/s an titan angebunden) wird nur mit etwa 15 MBit/s ins Internet weitergereicht
      • in einem vergleichbaren Beispielsetup mit einfachem NAT (über zwei Router, 100 MBit/s-Verkabelung) sind spontan ca. 85 MBit/s verfügbar
      • in irgendeiner Form wird die Upstream-Bandbreite der APs beim Durchgang durch titan ausgebremst


Weitere Aktivitäten

Unverschlüsseltes VPN

Gelegentlich kam der Gedanke auf, optional ein OpenVPN ohne Verschlüsselung anzubieten, um die CPU-Last bei intensivem Netzwerkverkehr zu reduzieren. Die obigen Zahl deuten darauf hin, dass der Effekt recht gering wäre. Somit ist diese Handlungsoption wohl nicht relevant für zukünftige Planungen.

KVM- und Bridge-Performance

Möglicherweise verursacht die Netzwerkkonfiguration des virtuellen Servers den Geschwindkeitsverlust (opennet->Internet). Übliche Verbesserungsmöglichkeiten:

Eine Beobachtung der Kernelthreads des Virtualisierungsservers bei starkem Netzverkehr wäre vielleicht hilfreich.


Notizen

iperf auf WRT54GL (white russian)

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge