Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| anleitungen:troubleshooting [22.10.2019 - 08:48] – [Bandbreite und Latenz] Wilhelm | anleitungen:troubleshooting [22.10.2019 - 09:10] (aktuell) – [Weitere Probleme] Wilhelm | ||
|---|---|---|---|
| Zeile 42: | Zeile 42: | ||
| Die Geschwindigkeit von TCP hängt von der Bandbreite, von der Latenz und der Verbindungsqualität (Paketverlust) ab. | Die Geschwindigkeit von TCP hängt von der Bandbreite, von der Latenz und der Verbindungsqualität (Paketverlust) ab. | ||
| - | A) Die Latenz steigt mit jedem Punkt auf dem Weg zum Ziel. | + | == A) Die Latenz steigt mit jedem Punkt auf dem Weg zum Ziel == |
| - Nummerierter Listenpunkt Client - Node | - Nummerierter Listenpunkt Client - Node | ||
| * Hier via WLAN | * Hier via WLAN | ||
| Zeile 67: | Zeile 67: | ||
| Meine Erfahrung sagt Glasfaser direkt bringen: | Meine Erfahrung sagt Glasfaser direkt bringen: | ||
| - | | + | * Stuttgart-München: |
| - | Stuttgart-Karlsruhe: | + | |
| - | Wenn ich hier die Spielekiste an mache, dann sagt mir mein System, direkt, | + | |
| - | ohne Freifunk, 55ms zu den battle.net-Servern. Das ist die in der | + | Wenn ich hier die Spielekiste an mache, dann sagt mir mein System, direkt,ohne Freifunk, 55ms zu den battle.net-Servern. Das ist die in der Applikation angezeigte Latenz. Die ist normalerweise schlechter als 'ICMP echo'. Auch das muss bei Vergleichen berücksichtiogt werden. |
| - | Applikation angezeigte Latenz. Die ist normalerweise schlechter als 'ICMP | + | |
| - | echo'. Auch das muss bei Vergleichen berücksichtiogt werden. | + | |
| Die großen Teile der Latenz sind | Die großen Teile der Latenz sind | ||
| - | - der lokale Internetzugang | + | * der lokale Internetzugang |
| - | - der Weg vom GW zum Ziel, abhängig vom Ziel, Content Delivery Networks | + | |
| - | | + | |
| Relativ irrelevant ist der Weg zum GW. gw08n01 ist von mir 7ms weiter | Relativ irrelevant ist der Weg zum GW. gw08n01 ist von mir 7ms weiter | ||
| - | weg als gw05n03 | + | weg als bei gw05n03. Der Ping durch das Freifunk-Netz zu eu.battle.net ist |
| aber nur <6ms langsamer. | aber nur <6ms langsamer. | ||
| + | |||
| via gw08n01: | via gw08n01: | ||
| - | round-trip min/avg/max = 42.433/ | + | * round-trip min/avg/max = 42.433/ |
| - | lokal direkt ohne Freifunk: | + | |
| - | rtt min/ | + | * rtt min/ |
| + | |||
| + | == B) Bandbreite im Freifunknetz == | ||
| + | |||
| + | Diese resultiert aus der kleinsten Bandbreite aller beteiligten Hops zum Ziel. | ||
| - | B) Bandbreite im Freifunknetz, | + | Normalerweise ist die geringste Bandbreite der lokale Internetzugang oder die WLAN/ |
| - | aller beteiligten Hops zum Ziel. Normalerweise ist die geringste | + | |
| - | Bandbreite der lokale Internetzugang oder die WLAN/ | + | |
| - | Da muss jeder lokal selbst nach einer Optimierung suchen. Bekannte | + | |
| - | Methoden sind z.B. Mesh-on-LAN und getrennte Client/ | + | |
| - | unterschiedlichen Kanälen | + | |
| - | C) Packet Loss, wenn TCP Pakete verliert, wird meistens mit einer Reduzierung | + | == C) Packet Loss == |
| - | der Bandbreite reagiert. Paketverlust tritt in Deutschland im festen | + | Wenn TCP Pakete verliert, wird meistens mit einer Reduzierung der Bandbreite reagiert. Paketverlust tritt in Deutschland im festen Internet heute nur sehr wenig auf, in WLAN-Netzen aufgrund von Störungen aber doch recht häufig. Hier kann der Client und der Serverbetreiber eventuell durch lokale Einstellungen die Auswirkungen lindern. Die Serverbereiber werden wir kaum erreichen, die Clients sind die User selbst. |
| - | Internet heute nur sehr wenig auf, in WLAN-Netzen aufgrund von Störungen | + | |
| - | aber doch recht häufig. | + | |
| - | Hier kann der Client und der Serverbetreiber eventuell durch lokale | + | |
| - | Einstellungen die Auswirkungen lindern. Die Serverbereiber werden wir | + | |
| - | kaum erreichen, die Clients sind die User selbst. | + | |
| - | Zentral können wir nur an A drehen und auch da nur am Standort der GWs. | + | Zentral können wir nur an A drehen und auch da nur am Standort der GWs. Die sollten so nah wie möglich an den Clients (Internetprovider) und an den Zielen liegen. Die Ziele sind uns nicht bekannt. Die Provider selbst recht gut angebunden. Wir können natürlich pauschal GWs ablehnen, die nicht an großen deutschen Austauschpunkten sind, aber selbst nach Paris sind es nur 7ms mehr, ich glaube nicht dass das den Durchsatz erhöht. Selbst eine Verbindung nach Shanghai (250ms Latenz) schafft anständige Bandbreiten wenn die Leitung nicht gerade überlastet ist. |
| - | Die sollten so nah wie möglich an den Clients (Internetprovider) und | + | |
| - | an den Zielen liegen. Die Ziele sind uns nicht bekannt. Die Provider | + | |
| - | selbst recht gut angebunden. Wir können natürlich pauschal GWs ablehnen, | + | |
| - | die nicht an großen deutschen Austauschpunkten sind, aber selbst nach | + | |
| - | Paris sind es nur 7ms mehr, ich glaube nicht dass das den Durchsatz | + | |
| - | erhöht. Selbst eine Verbindung nach Shanghai (250ms Latenz) schafft | + | |
| - | anständige Bandbreiten wenn die Leitung nicht gerade überlastet ist. | + | |
| - | Die größten Einsparungen an der Latenz bringen lokale, direkt ausleitende | + | Die größten Einsparungen an der Latenz bringen lokale, direkt ausleitende GWs an Leitungen die nicht DSL-Latenzen bringen. Aber auch das wird kaum |
| - | GWs an Leitungen die nicht DSL-Latenzen bringen. Aber auch das wird kaum | + | eine Auswirkung auf die Bandbreite haben. Dicke Internetanbindungen und gut aufgesetze WLAN-Installationen bringen da bis zur Kapazitätsgrenze der GWs sicher am meisten. Letzere lassen sich mit lokalen Ausleitungen umgehen, dafür gibt es aber noch keine einfache Möglichkeit. |
| - | eine Auswirkung auf die Bandbreite haben. | + | |
| - | Dicke Internetanbindungen und gut aufgesetze WLAN-Installationen bringen | + | |
| - | da bis zur Kapazitätsgrenze der GWs sicher am meisten. Letzere lassen | + | |
| - | sich mit lokalen Ausleitungen umgehen, dafür gibt es aber noch keine | + | |
| - | einfache Möglichkeit. | + | |
| - | Wenn die Bandbreite zum User trotz sauberer lokaler Installation mit | + | Wenn die Bandbreite zum User trotz sauberer lokaler Installation mit ausreichend starkem VPN-Node noch gering ist, kann es auch an einem ausgelasteten GW liegen. Das läßt sich unter https:// |
| - | ausreichend starkem VPN-Node noch gering ist, kann es auch an einem | + | morgens hoch geht und dann den Tag über eher flach ist, am Abend wieder runter geht, dann ist das GW ausgelastet. Prinzipiell haben wir ausreichend Kapazitäten auf den GWs, aber wir haben derzeit keine Möglichkeit Nodes auf andere GWs zu schicken um die verfügbare Bandbreite besser zu verteilen. Das Gateway wird derzeit bei der Verbindung von den Nodes zufällig gewählt. |
| - | ausgelasteten GW liegen. Das läßt sich unter https:// | + | |
| - | an der Abwesenheit von Kurven beim eth0-Traffic erkennen. Wenn das | + | |
| - | morgens hoch geht und dann den Tag über eher flach ist, am Abend | + | |
| - | wieder runter geht, dann ist das GW ausgelastet. | + | |
| - | Prinzipiell haben wir ausreichend Kapazitäten auf den GWs, aber wir | + | |
| - | haben derzeit keine Möglichkeit Nodes auf andere GWs zu schicken um | + | |
| - | die verfügbare Bandbreite besser zu verteilen. Das Gateway wird | + | |
| - | derzeit bei der Verbindung von den Nodes zufällig gewählt. | + | |
| Stand: Mo 21. Okt 10:23:04 CEST 2019 | Stand: Mo 21. Okt 10:23:04 CEST 2019 | ||
| Zeile 167: | Zeile 139: | ||
| Auf dem Client, tja, keine Ahnung wie man da mit Windows tiefer analysiert, unter Linux oder auch MacOS mit root ist es einfacher. | Auf dem Client, tja, keine Ahnung wie man da mit Windows tiefer analysiert, unter Linux oder auch MacOS mit root ist es einfacher. | ||
| - | 1. hat der Client eine IP? | + | - hat der Client eine IP? |
| - | 2a nein: Gibt es Traffic auf dem WLAN-Interface? | + | * 2a nein: Gibt es Traffic auf dem WLAN-Interface? |
| - | 3a nein: WLAN ist nicht richtig, da kommt immer was, mindestens ARP Requests ab und an. Client hat irgendein lokales Problem. | + | * 3a nein: WLAN ist nicht richtig, da kommt immer was, mindestens ARP Requests ab und an. Client hat irgendein lokales Problem. |
| - | 3b ja: WLAN zum Node steht, wahrscheinlich keine IP vom GW, GW-Betreiber kontaktieren, | + | * 3b ja: WLAN zum Node steht, wahrscheinlich keine IP vom GW, GW-Betreiber kontaktieren, |
| - | 2b ja: funktioniert ping auf 8.8.8.8? | + | * 2b ja: funktioniert ping auf 8.8.8.8? |
| - | 4a ja: funktioniert ping auf heise.de? | + | * 4a ja: funktioniert ping auf heise.de? |
| - | 5a ja: Es gibt kein Problem. | + | * 5a ja: Es gibt kein Problem. |
| - | 5b nein: DNS funktioniert nicht. Lokal genutzten DNS-Server pruefen, oft sind da noch Reste vom anderswo drin. Richtig waere zumindest einer der so heisst wie das Gateway. Wenn die korrekt sind: GW-Betreiber kontaktieren., | + | * 5b nein: DNS funktioniert nicht. Lokal genutzten DNS-Server pruefen, oft sind da noch Reste vom anderswo drin. Richtig waere zumindest einer der so heisst wie das Gateway. Wenn die korrekt sind: GW-Betreiber kontaktieren., |
| - | 4b nein: Internet geht schonmal nicht. Geht ping auf das Default Gateway? | + | * 4b nein: Internet geht schonmal nicht. Geht ping auf das Default Gateway? |
| - | 6a ja: GW-Betreiber kontaktieren, | + | * 6a ja: GW-Betreiber kontaktieren, |
| - | 6b nein: phuu, WLAN neu starten, wahrscheinlich hat er dann keine IP mehr, weiter bei 2a. Oder es funktioniert jetzt. | + | * 6b nein: phuu, WLAN neu starten, wahrscheinlich hat er dann keine IP mehr, weiter bei 2a. Oder es funktioniert jetzt. |
| ===== Probleme beim Flashen der Firmware ===== | ===== Probleme beim Flashen der Firmware ===== | ||