Wlan und VOIP: Welche Bandbreite?

[BenutzerGa4gooPh]

@wanne:

Router macht im Optimalfall größenordnungsmäßig 0.1ms bei 100MBit/s und 0.01ms bei GBit/s. In der realität ehr das Doppelte oder so. Bei nem billigen auch gerne mal das zehnfache. Wenn da genug drin stehen, merkt man das. Im Normalfall eher nicht.

Ich hatte für die Abschätzung nur meine rund 40ms ping-Zeit durch 10 Hops zu http://www.google.de geteilt, waren eigentlich 11 Hops. Aber egal, eine korrekte Messung ist das nicht, war nur interessant, welches delay ein Internet-Router im Mittel und ohne weitere Massnahmen so hat. War auch keine Langzeitmessung. Hast schon Recht, mit gewissen Massnahmen bei Beachtung der Netztopologie erreicht man sicher Besseres (oft nur im Mittel), nimmt aber auch Nachteile in Kauf. Ich denke gerade mal an groessere Rahmenlaengen im WLAN bei mehreren Clients. Queing bei VoIP/Live-Video ist wohl sehr zu überlegen (delay), vlt. geringfügig zum Ausgleich von jitters.

[wanne]

Ich hatte für die Abschätzung nur meine rund 40ms ping-Zeit durch 10 Hops

Das sind nicht 10 Hops sondern deutlioch mehr. Die Provider machen intern halt MPLS und zählen die TTL da nicht runter. Deswegen siehst du die nicht. Aber die Router auf dem weg haben noch viel kleinere Latenzen.
Auf meinem Server sehe ich zu 8.8.8.8 17 hops und bin bei 10ms. 4ms davon sind zwischen 2 hops.

Für eine Interentverbindung hast du typischerweise nur diese relevanten Verzögerungen:

• Die Lichtgeschwindigkeit in Glas ist ~2·10⁸m/s. Nach Australien hast du da selbst bei direkter route über die Oberfläche 182ms Signallaufzeit. Nach San Francisco 92ms. Einfach durch die Lichtgeschwindigkeit und die Entfernung. Deswegen kann man mit Leuten in den USA nicht CoD oder so zoken. München-Hamburg ist dagegen nur 6ms. Hamburg-Málaga 21ms. Das ist dann weniger relevant.
• Die DSL Modem+DSLAM haben eine relativ große latenz. Das sind bei ADSL gerne mal 20-30ms.
• Die Anbindung zum DSL ist ganz gerne mal überlastet. Statt Pakete wegzuwerfen puffern die Provider oft wie verrückt, und hoffen auf bessre Zeiten/weniger Auslastung. Da können dann mal gefühlt so bis zu 80ms draufgehen. Aber das ist eher selten. Das passiert dann auch nur um 18:00Uhr oder so.

Achso und messt am besten mit TCP/UDP. Nicht mit ping. Die provider priorisieren da: von einigen wird ICMP einfach grauenhaft verwendet und die schicken das über irgend eine route auf mini Bandbreiten. Andere drosseln UDP passiev aus.

[BenutzerGa4gooPh]

Das sind nicht 10 Hops sondern deutlich mehr. Die Provider machen intern halt MPLS und zählen die TTL da nicht runter.

Yes, Sir. Wobei ich persönlich Layer-2-Geräte (Switches) nicht als Hops bezeichnen würde - aber das mag Geschmacks- oder Philosophiefrage sein.
https://de.wikipedia.org/wiki/Hop_%28Ne ... nologie%29

Wichtig in dem Zusammenhang erscheint mir, dass Latenzen (neben Pufferung) im Nahbereich von Software verursacht werden - und das ist eher bei Routern mit mehr Protokollschichten und weniger zusammengefassten Ports der Fall. Damit meine ich Internet-BGP-Router, die mehr oder weniger nur "Trunk-Ports" besitzen, zwischen diesen routen. (Bei DSLAMs und Broadband Remote Access Servers wird natürlich mit erheblicher Überbuchung/Pufferung der Trunks gearbeitet, für Sprache wohlweislich weniger.) Im switched MPLS-Backbone werden Probleme zumeist mit Bandbreite erschlagen und Sprache wird priorisiert. Aber wir wollen uns nicht um Kaisers Bart streiten, ist eh spekulativ, da man die genaue Topologie nicht kennt.

Warum ich eigentlich schreibe ist:

Auf meinem Server sehe ich zu 8.8.8.8 17 hops und bin bei 10ms. 4ms davon sind zwischen 2 hops.

Das könntest du mal näher ausführen, wie du das ermittelt hast (ping und traceroute?) Ist denn meine Netzanbindung so schlecht, zu 8.8.8.8 über 7 Router (traceroute) mit etwa 40ms mittlere ping-Zeit? Gerade noch mal (3 min lang) probiert. Wie gesagt, WLAN-Backbone für gesamtes Dorf, nix DSL... .

Achso und messt am besten mit TCP/UDP.

Bitte auch etwas näher ausführen, wie denn Zeiten besser messen, Bandbreitenmessungen sind ja bekannt, aber Zeiten ... . Special software package? Hier lassen wir vlt. erst mal Sprache/Video außen vor, geht nur um allgemeine Netzqualität ohne Priorisierung, Codecs.

Sprache/Video, persönliche Meinung: Für eine exakte Messung müsste man eine VoIP-Lösung Ende zu Ende aufbauen, bei einer Hybridlösung (VoIP mit analogen oder ISDN-Anschlüssen) mit (teurer) TDM-Messtechnik messen, für hybrides und native VoIP Siganlanalysen im Zeit- oder Frequenzbereich (z. B. Matlab, Octave) durchführen.

OT für alle Mitleser:
Da wir im Smalltalk sind und es gerade zum Thema passt, gestern zufällig gelesen:
Was ist eine Theoretiker? Der Theoretiker kennt 100 Stellungen - jedoch keine Frau. (Eigene Anmerkung: Oder nur eine Theoretikerin.)

[dufty2]

Ich hatte für die Abschätzung nur meine rund 40ms ping-Zeit durch 10 Hops zu http://www.google.de geteilt

Na, mit g**gle habt Ihr Euch aber das denkbar ungünstigste Ziel ausgesucht, denn

Code: Alles auswählen

$ host www.google.de
www.google.de has address 172.217.16.195
$ host 172.217.16.195
195.16.217.172.in-addr.arpa domain name pointer fra16s08-in-f3.1e100.net.

$ host www.google.de
www.google.de has address 216.58.211.3
$ host 216.58.211.3
3.211.58.216.in-addr.arpa domain name pointer muc03s13-in-f3.1e100.net.

"fra" könnte Frankfurt sein und "muc" vermutlich München.

Und je nachdem, wo man sich in der Republik befindet, ist es mal weiter, mal weniger weit weg:

Code: Alles auswählen

$ ping -c 10 216.58.211.3
PING 216.58.211.3 (216.58.211.3) 56(84) bytes of data.
64 bytes from 216.58.211.3: icmp_req=1 ttl=56 time=4.07 ms
64 bytes from 216.58.211.3: icmp_req=2 ttl=56 time=3.84 ms
64 bytes from 216.58.211.3: icmp_req=3 ttl=56 time=3.98 ms
64 bytes from 216.58.211.3: icmp_req=4 ttl=56 time=3.97 ms
64 bytes from 216.58.211.3: icmp_req=5 ttl=56 time=4.04 ms
64 bytes from 216.58.211.3: icmp_req=6 ttl=56 time=3.96 ms
64 bytes from 216.58.211.3: icmp_req=7 ttl=56 time=3.82 ms
64 bytes from 216.58.211.3: icmp_req=8 ttl=56 time=4.05 ms
64 bytes from 216.58.211.3: icmp_req=9 ttl=56 time=3.92 ms
64 bytes from 216.58.211.3: icmp_req=10 ttl=56 time=3.88 ms

--- 216.58.211.3 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9010ms
rtt min/avg/max/mdev = 3.822/3.958/4.078/0.087 ms
$

Und 8.8.8.8 bzw. 8.8.4.4 sind Anycast-Adressen ...

[BenutzerGa4gooPh]

Na, mit g**gle habt Ihr Euch aber das denkbar ungünstigste Ziel ausgesucht, ...

Nu ja vielleicht. ... Bei Mittelung durch Anzahl Hops?! Jedenfalls bist du schnell - wortwörtlich im doppeltem Sinn. Und jetzt schlage ich "Anycast Adresse" nach.

Anycast ist eine Adressierungsart in Computernetzen, bei der man über eine Adresse einen einzelnen Rechner aus einer ganzen Gruppe von Rechnern ansprechen kann. Es antwortet derjenige, der über die kürzeste Route erreichbar ist.

Jepp, reine ping-Zeiten sind wenig aussagekräftig und schon gar nicht vergleichbar. Trotzdem wohne ich wahrscheinlich in China. Dein Posting gibt mir Anlass zu forschen ... das mit den 4 ms/Hop als Mittelwert zu verallgemeinern ... ich lag wohl ganz schön daneben.

[wanne]

Yes, Sir. Wobei ich persönlich Layer-2-Geräte (Switches) nicht als Hops bezeichnen würde - aber das mag Geschmacks- oder Philosophiefrage sein.

Die Frage ist ob man MPLS als Layer 2 betrachtet.

Ist denn meine Netzanbindung so schlecht, zu 8.8.8.8 über 7 Router (traceroute) mit etwa 40ms mittlere ping-Zeit?

Normal für ein Klassiches 56k Modem oder ADSL. ISDN schneidet normal deutlich besser ab.

Das könntest du mal näher ausführen, wie du das ermittelt hast (ping und traceroute?)

In dem Fall ist beides gleich.

DBitte auch etwas näher ausführen, wie denn Zeiten besser messen, Bandbreitenmessungen sind ja bekannt, aber Zeiten ... .

Am einfachsten kannst du das machen in im Wireshark Zeiten von TCP ACKs bei ssh oder telnet anguckst. SSL Haertbeat eigenet sich auch hervorragend zu sowas. Sonst gibt es noch tools wie echoping oder httping. muss man aber immer beachten, dass die Server eventuell nicht instanatn reagieren. Sonst natürlich noch traceroute. Aber das ist auf dem Rückweg dann auch ICMP.

[BenutzerGa4gooPh]

Yes, Sir. Wobei ich persönlich Layer-2-Geräte (Switches) nicht als Hops bezeichnen würde - aber das mag Geschmacks- oder Philosophiefrage sein.

Die Frage ist ob man MPLS als Layer 2 betrachtet.

Der war gut, demzufolge kein Kommentar möglich.

Sonst gibt es noch tools wie echoping oder httping.

Kannte ich nicht, schaue ich mir an. Selbst im Smalltalk lernt man dazu.

Kurzes Fazit für den TE:
Meine langen ping-Zeiten werden mit hoher Wahrscheinlichkeit durch den WLAN-Backbone unseres Dorfes verursacht. Forsche ich mal nach und melde mich irgendwann.
Trotzdem betreiben manche hier VoIP. Also, probieren geht über studieren, man muss sich mit ähnlich schlechten Zeiten im WLAN wohl nicht allzuviele Sorgen machen - zumindest nicht bei privatem Einsatz. Für mich war interessant, was andere für Zeiten haben. Dadurch, dass ich meist nur Websites/Downloads nutze, sind mir meine bisher gar nicht negativ aufgefallen. Danke dufty2 und wanne.

[heisenberg]

Auch nochmal ein Kommentar zum Thema Bandbreite und WLAN und Puffer:

Ich habe die Tage mal ein bisschen zum Thema Videostreaming mit VLC(VLC auf Server+Clients) gespielt. Endergebnis:

• Ein MPEG1 RTP-Stream hat ca. 600 KBit/Sec Last mit Multicast verursacht(Auf 802.11b WLAN mit 54 MBit/Sek Brutto)
• Die Qualität auf den Android Clients war nach längerem Optimieren(Server und Client) gerade so ausgereichend. Gelegentliche Artefakte gab es trotzdem noch.
• Das WLAN war damit voll ausgelastet. Alle zusätzlichen Datenübertragungen wurden sofort drastisch gestört.

Das hat mich doch etwas verwundert, zumal ich nur etwas über 1% der Brutto-Kapazität in Dauerlast verwendet habe. Der Aufbau hat auch nur funktioniert, als ich die Sendestation per Kabel angeschlossen habe. Beim senden von einem Gerät direkt per WLAN war die Qualität wieder total mies(Massig Artefakte).

Der Meinung "einfach ausprobieren und wenn's geht ist es gut" stimme ich auch voll zu. Das reicht fast immer.

[wanne]

Auf 802.11b WLAN mit 54 MBit/Sek Brutto

802.11b macht maximal 11MBit/s. Ich nehme an, du meinst 802.11g. Aber auch da ist das die maximal aushandelbare Bandbreite. 802.11g kennt verschiedene Modi, die je nach Situation genutzt werden. Oft handeln die Clients schon einen Modi mit deutlich weniger aus. Und dann ist das die Maximale Brutodatenrate. Gibt es Fehler wird das langsamer. Und Brutto und Netto unterscheidet sich bei WLAN auch noch massiv.

Dazu glaube ich kaum, dass die meisten WLAN APs vernünftig Multicast können. Cisco wirbt damit, dass seine das können. Wahrscheinlich verschickt der AP schlicht an jeden Client einzeln.
Dazu kommt, dass RTP darauf ausgelegt ist Bei relativ wenig Bandbreitenverbrauch Verzögerungsfrei zu streamen. Das ganze am Limit der Leitung zu betreiben, funktioniert eher nicht, da sollte dann automatisch die Qualität Serverseitig runtergestellt werden. Das liegt bedingt an der UDP Nutzung auf der einen Seite ist es aggressiv, und verträngt TCP Verbindungen, auf der anderen Seite bekommt es massive Probleme mit überlasteten Leitungen, weil dann Pakete einfach weggeworfen werden.

Zu aller Letzt stellt sich der VLC auch irgend wie doof an. Ich weiß nicht warum aber das klappt mit anderen RTP Servern besser. Kp, warum. Habe das Gefühl, als ob der unkontinuierlich arbeitet oder so. Habe das gefühl der sendet immer kurz mit der maximal angegebenen Bandbreite an der Eingangsleitung und macht dann eine Weile nichts.

[heisenberg]

802.11b macht maximal 11MBit/s. Ich nehme an, du meinst 802.11g.

Ja. Man möge mir verzeihen. Es ist 802.11g.

Dazu glaube ich kaum, dass die meisten WLAN APs vernünftig Multicast können. Cisco wirbt damit, dass seine das können. Wahrscheinlich verschickt der AP schlicht an jeden Client einzeln.

Das ist in der Tat eine wichtige Information. Ich hatte nur 3 Clients.

Dazu kommt, dass RTP darauf ausgelegt ist Bei relativ wenig Bandbreitenverbrauch Verzögerungsfrei zu streamen. Das ganze am Limit der Leitung zu betreiben, funktioniert eher nicht, da sollte dann automatisch die Qualität Serverseitig runtergestellt werden.

Ist für Dich mein Anwendungsfall ein Betrieb am Limit? ~1% Kapazität bei 3 Clients? (Auch wenn Multicast tatsächlich nicht funktionieren sollte). Der Betrieb war ein reiner Testbetrieb. D. h. alle Geräte nur wenige Meter voneinander entfernt.

Zu aller Letzt stellt sich der VLC auch irgend wie doof an. Ich weiß nicht warum aber das klappt mit anderen RTP Servern besser. Kp, warum. Habe das Gefühl, als ob der unkontinuierlich arbeitet oder so. Habe das gefühl der sendet immer kurz mit der maximal angegebenen Bandbreite an der Eingangsleitung und macht dann eine Weile nichts.

Im Netzwerkmonitor sieht das aber recht sauber aus. Der Datenstrom ist annähernd auf einem Level. Mit welchen Streaming-Servern hast Du bessere Erfahrungen gemacht?

[wanne]

Ist für Dich mein Anwendungsfall ein Betrieb am Limit? ~1% Kapazität bei 3 Clients? (Auch wenn Multicast tatsächlich nicht funktionieren sollte). Der Betrieb war ein reiner Testbetrieb. D. h. alle Geräte nur wenige Meter voneinander entfernt.

Das kommt drauf an. Wenn du du dein Kabel von PC zu PC spannst, kannst du da mehr oder weniger die volle Bandbreite Drüberziehen – Mehr als das mit TCP ginge. Nur wenn du halt deinen Dowload startest, ist die Leitung kurzzeitig am Limit, weil der sich halt nimmt was er bekommt. UDP setzt dann seinen Traffic oben drauf und das bringt das Fass zum Überlaufen, und dir bricht beides zusammen. Deswegen willst du für sowas eigentlich hierarchische Infrastruktur haben. Nicht das GBit/s Ethernet vor deinem 16MBit/s DSL. Mit kleinen Queues kannst du das mehr oder weniger simulieren. Setzt du die auf extrem kleine Werte, fühlt sich dein ganzer vorderer Teil so an, als ob er auf die 16MBit/s. Das gleiche Problem hast du mit mehreren Clients in deinem WLAN. Jeder Client meint, er hätte die vollen 54MBit/s und in Wahrheit teilen sie sich die halt alle.
Vor allem: Deine WLAN Brutto Datenraten sind Bullshit. Zuerstmal musst du beachten, dass ohne Kabel immer hin und her gesendet wird, zum zweiten solltest du wirklich mal gucken, was da ausgehandelt wurde. 54MBit/s oder doch eher 11MBit/s? Zuletzt ist WLAN halt instabiel. Für deinen Livestream ist aber eben die minimale Bandbreite relevant. Nicht der average oder so. Und zum Endet nutzen moderne APs eben die Hälfte des Spektrums. Zusammen mit Mikrowellen, Bluetooth Geräten und Funkfernbedienungen. Alleine bist du da selten. Mit dem rest teilst du dir die Bandbreite. Und beim Teilen kommt da nicht zwei mal die hälfte raus sondern gerade wenn du mit der Mikrowelle arbeitest macht die kein CSMACA. Die sendet halt einfach. Dein Wlan ist auf sowas ganz und gar nicht vorbereitet.

Zu aller Letzt stellt sich der VLC auch irgend wie doof an. Ich weiß nicht warum aber das klappt mit anderen RTP Servern besser. Kp, warum. Habe das Gefühl, als ob der unkontinuierlich arbeitet oder so. Habe das gefühl der sendet immer kurz mit der maximal angegebenen Bandbreite an der Eingangsleitung und macht dann eine Weile nichts.

Im Netzwerkmonitor sieht das aber recht sauber aus. Der Datenstrom ist annähernd auf einem Level. Mit welchen Streaming-Servern hast Du bessere Erfahrungen gemacht?[/quote]