Wie beeinflusst die Netzwerklatenz Plex bei gleichzeitiger Nutzung durch verschiedene Clients?

Netzwerklatenz beeinflusst Plex mit gemischten Clients, indem sie den Start, das Spulen und das Auffüllen des Puffers verzögert, während gemeinsam genutzte Verbindungen durch überlappende Sitzungen zusätzliche Warteschlangen bilden.

Ein kabelgebundener Fernseher, ein WLAN-Tablet und ein Smartphone aus der Ferne können denselben Server über sehr unterschiedliche Wege erreichen. Daher kombiniert die gleichzeitige Nutzung unterschiedliche Latenzen und Übertragungsraten, anstatt einen identischen Stream einfach zu vervielfachen. Das auftretende Problem hängt vom Pufferspielraum ab: Kurze Verzögerungen verschwinden möglicherweise, sobald die Wiedergabe läuft, während Jitter oder Warteschlangen einen Client ausbremsen können, der bereits nahe an seiner Übertragungsgrenze lag.

Latenz zeigt sich zuerst durch Verzögerungen beim Start und Spulen

Netzwerklatenz fällt am leichtesten auf, wenn der Client auf die ersten nützlichen Daten warten oder seinen Puffer nach dem Spulen neu aufbauen muss. Eine laufende Wiedergabe kann flüssig bleiben, sobald genügend Daten vorgeladen sind. Ein langsamer Start bedeutet daher nicht automatisch, dass der Verbindung durchschnittliche Bandbreite fehlt.

In Diskussionen zu Remote-Clients wird darauf hingewiesen, dass Netzwerklatenz stärker auffallen kann, wenn der Übertragungsweg Repeater oder andere Verzögerungen umfasst. Der diagnostische Hinweis ist, ob sich Start oder Wiederaufnahme nach dem Spulen verschlechtern, bevor der anhaltende Datendurchsatz abnimmt.

Messen Sie für dieselbe Datei getrennt die Zeit bis zum ersten Bild, die Erholungszeit nach dem Spulen und die laufende Wiedergabe. Wenn die ersten beiden Werte über einen Weg mit höherer Latenz steigen, der Stream nach dem Puffern jedoch flüssig bleibt, ist Latenz wahrscheinlich das Hauptproblem. Wenn der Puffer während der Wiedergabe wiederholt leer läuft, muss zusätzlich die kontinuierliche Datenübertragung untersucht werden.

Gemischte Clients erreichen den Server über unterschiedliche Netzwerkwege

In einem Haushalt kann ein Fernseher kabelgebunden im LAN verbunden sein, ein Tablet über einen Mesh-Hop im WLAN laufen und ein Smartphone Plex über das Internet erreichen. Diese Clients haben nicht dieselbe Latenz, denselben Paketverlust oder dieselbe Bandbreite, obwohl sie denselben Medienserver verwenden. Gleichzeitige Nutzung kombiniert daher unterschiedliche Netzwerkbedingungen.

Direct Play über einen entfernten Speicher- oder Netzwerkpfad kann empfindlich auf den Puffer des Clients reagieren, weil das Pufferverhalten bei hohen Bitraten weniger serverseitige Konvertierungspufferung bietet, um Schwankungen bei der Übertragung auszugleichen. Ein langsamer Endpunkt beweist nicht, dass der Server überlastet ist.

Kennzeichnen Sie jede Sitzung sowohl nach ihrem Übertragungsweg als auch nach dem Wiedergabemodus. Wenn nur der Mesh-Client langsamer wird, während der kabelgebundene Client problemlos läuft, sollten Sie die beiden nicht zu einem serverweiten Latenzproblem zusammenfassen. Wenn alle Clients gleichzeitig langsamer werden, suchen Sie nach einer gemeinsamen Serververbindung, einer Speicherabhängigkeit oder einem vorgelagerten Netzwerkpfad.

Latenz verringert den dem Client-Puffer verfügbaren Spielraum

Ein Puffer wandelt kurze Netzwerkverzögerungen in unsichtbare Unterbrechungen bei der Datenankunft um. Höhere Latenz und Jitter verbrauchen diesen Schutz, weil das Nachladen weniger vorhersehbar wird – insbesondere, wenn die Bitrate der Datei schwankt oder der Client nur einen kleinen Puffer verwendet. Derselbe durchschnittliche Datendurchsatz kann sich daher über zwei verschiedene Wege unterschiedlich anfühlen.

Ein Plex-Fall mit hoher Latenz zeigt instabile Wiedergabe, obwohl die nominelle Bandbreite ausreichend erscheint. Daher sollte Streaming mit hoher Latenz anhand des Pufferverhaltens und nicht nur anhand eines Ergebnisses vom Geschwindigkeitstest geprüft werden.

Beobachten Sie, ob sich der Client während ruhiger Szenen erholt und bei Bitratenspitzen aussetzt. Wenn die Latenz den Pufferspielraum aufbraucht, kann eine Verringerung der angeforderten Bitrate die Stabilität verbessern, ohne die Serverberechnung zu verändern. Wenn die Sitzung danach transkodiert wird, trennen Sie die Netzwerkbehebung von der dadurch entstehenden zusätzlichen Rechenlast.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Gleichzeitige Nutzung erzeugt Warteschlangen auf gemeinsam genutzten Verbindungen

Mehrere Clients können die Latenz indirekt erhöhen, indem sie die gemeinsam genutzte WLAN-Sendezeit, die Router-Warteschlange, den WAN-Uplink oder die Serverschnittstelle auslasten. Die zusätzliche Verzögerung kann auftreten, bevor die Verbindung eine einfache Auslastungsgrenze erreicht, da Warteschlangen und Wiederholungsübertragungen bei den Datenbursts mehrerer Sitzungen zunehmen.

Pufferprobleme bei Direct Play können entstehen, wenn das Netzwerk Daten nicht schnell genug liefern kann. Grenzen der Wiedergabe bei hoher Latenz lassen sich besser beurteilen, wenn man sie vor und nach dem Start eines weiteren Clients vergleicht. Die zweite Sitzung ist eine kontrollierte Möglichkeit, eine Warteschlange zu erzeugen.

Starten Sie einen repräsentativen Client, erfassen Sie Latenz und Datendurchsatz und fügen Sie anschließend den zweiten und dritten Client hinzu, ohne die Dateien zu ändern. Wenn die Round-Trip-Zeit oder der Paketverlust steigt, bevor die Wiedergabe schlechter wird, ist das gemeinsam genutzte Netzwerk Teil des Problems bei gleichzeitiger Nutzung. Bleiben die Netzwerkwerte stabil, sollten Sie wieder Speicher- oder Transkodierungsressourcen untersuchen.

Ein Test mit gemischten Clients trennt Netzwerkverzögerung von Serverarbeit

Latenz sollte geprüft werden, während der Wiedergabemodus des Servers bekannt ist. Ein Client, der transkodiert, verursacht zusätzliche Kodierungsverzögerungen und fordert möglicherweise eine niedrigere Bitrate an, während ein Direct-Play-Client den Übertragungsweg direkter sichtbar macht. Werden beide ohne Kennzeichnung des Modus verglichen, vermischen sich Netzwerk- und Rechenursachen.

Qualitätseinstellungen des Clients können beeinflussen, ob der Server einen Stream konvertiert. Daher gehört das Qualitätsverhalten des Clients in den Testaufbau und sollte nicht während des Tests geändert werden. Halten Sie die Anfrage konstant, während Sie den Übertragungsweg messen.

Verwenden Sie zunächst eine kabelgebundene lokale Direct-Play-Sitzung als Kontrolle und fügen Sie anschließend die tatsächlichen Remote- und WLAN-Clients hinzu. Erfassen Sie Wiedergabemodus, Latenz, Paketverlust, Auslastung der Serververbindung und Pufferprobleme gemeinsam. Wenn der aggregierte Datenverkehr zum Engpass wird, liefert der Test der gemeinsam genutzten Verbindung den nächsten Entscheidungspunkt.