Wir haben bei “wir müssen reden” in letzter Zeit ziemlich massive Audioprobleme, was mit an Sicherheit grenzender Wahrscheinlichkeit an der Leitung liegt, vermutlich an Michis Ende.
Meine Frage: gibt es Tools, um die Verbindung zu diagnostizieren woran es liegt? Gibt es Möglichkeiten zu messen, ob die Leitung jetzt besser oder gut genug ist?
Das einfachste ist ein ping zum Server im Terminal:
$ ping sip.studio-link.de
Weniger wichtig ist wie niedrig die Latenz ist, sondern wie stabil diese über einen längeren Zeitraum bleibt. Es sollten keine wiederkehrenden Peaks >100ms Differenz oder Paketverluste auftreten. Kleinere Abweichungen bis 20-30ms sollten kein Problem darstellen.
Am besten parallel den “echo” Test-Account anrufen, dann ist auch etwas Traffic auf der richtigen Verbindung.
Wenn du mir als PN mal eure Nummer gibst, kann ich mal in mein Monitoring schauen.
Danke für die Antwort. Habe mal einen ersten Test gemacht. (Werde das weiter beobachten). Nebenbei mich mit Studio-link mit mir selbst connected (wenn das mit Echo-test gemeint war). Allgemein:
“147 packets transmitted, 147 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 32.443/35.803/76.367/5.181 ms”
Die Latenz war ziemlich konstant über die Zeit immer irgendwo bei 35 ms.
Zur Info: Nutze ein 2017er Macbook mit osx 10.13.
Der WLAN-Stack von OSX ist einfach großer Mist. Wenn ich die SPON Startseite aufrufe, ergibt das (ohne echo) schon eine Latenz von 300ms bei mir über einen Zeitraum von 10 Sekunden. Das gleiche beim Starten von Mail, Slack, Dropbox etc.
Dasselbe über Ethernet: Latenz geht nie über 30ms.
mein ping war jetzt über wlan
…und hast du dabei mal normal in Safarai/$Browser rumgesurft? Wenn ich die Finger still halte, ist auch über WLAN alles schick, aber jegliche Aktivität bringt die Latenz sofort aus dem Tritt. MBP 2015 MacOS 10.13.4
Ok, Experiment wiederholt während ich alle Tabs meines Safaris (das sind einige …) reloadet habe.
— sip.studio-link.de ping statistics —
97 packets transmitted, 97 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 79.243/86.141/270.690/23.717 ms
Wobei sich der Wert bei Nichtaktivität bei etwa 82 ms eingependelt hat (vorher 35) und ich ständnig spitzen von über 150 ms drin hatte. einmal sogar 270.
Mit anderen Worten. Nicht am Rechner rumfummeln während der Aufnahme …
…oder besser: wenn es denn irgendwie geht Ethernet nehmen/verlegen. Das ist da komplett robust gegen, selbst bei bescheidenen Internetleitungen.
Ja, was war lange Zeit unsere Lösung. Mein neues Büro hat aber kein eigenen Anschluss (der ist auf dem Flur), weswegen ich da nicht so leicht mit Kabel rankomme … aber wir bekommen wahrscheinlich bald einen eignen, dann erledigt sich das.
Du könntest nochmal folgenden Hack probieren: wie ich die Lage sehe, liegt das Problem hier bei der konkreten Implementierung des WLAN-Stacks von MacOS, nicht bei der Qualität des Netzes an sich. Mit einem schnöden WLAN Extender/Repeater für 20 €, der zugleich einen Ethernet-Anschluss hat, könnte man das Problem vielleicht schon beheben - MacOS denkt es hat normales Ethernet, und das Netz dahinter ist vermutlich schnell genug.
klingt erst mal kontraintuitiv die Signalkette noch zu verkomplizieren, wären mir aber 20 € Ausprobieren wert.
Danke für den Tipp. Eben ausprobiert. Wir hatten deutlich weniger Probleme, was aber durchaus an anderen Faktoren liegen kann. Wir haben dann noch mal ohne Netzwerkkabel probiert und es war auch besser als das letzte Mal … kann also gut auch an ganz anderen Faktoren gelegen haben.
In zwei Wochen bekommen wir hier einen eigenen Anschluss. Dann mal sehen.
Ein sinnvoller A/B Versuchsaufbau wäre, im Hintergrund jeweils die ganzen Browsertabs neu zu laden oder anderen Traffic zu erzeugen.