Como é que a latência da rede afeta o Plex quando há utilização simultânea por clientes diferentes?

A latência da rede afeta o Plex com clientes mistos, atrasando o arranque, as procuras e o reabastecimento do buffer, enquanto as ligações partilhadas acrescentam filas à medida que mais sessões se sobrepõem.

Uma televisão ligada por cabo, um tablet em Wi-Fi e um telemóvel remoto podem solicitar o mesmo servidor através de percursos muito diferentes. Assim, a concorrência combina latências e débitos desiguais, em vez de multiplicar um único fluxo idêntico. O sintoma depende da margem do buffer: atrasos curtos podem desaparecer depois de a reprodução estar estabelecida, enquanto a instabilidade ou as filas podem esgotar o buffer de um cliente que já estava perto do seu limite de entrega.

A latência manifesta-se primeiro como atraso no arranque e nas procuras

A latência da rede é mais fácil de notar quando o cliente tem de esperar pelos primeiros dados úteis ou reconstruir o buffer depois de uma procura. A reprodução contínua pode manter-se fluida quando há dados suficientes em fila, por isso um arranque lento não significa automaticamente que a ligação tenha largura de banda média insuficiente.

Discussões sobre clientes remotos indicam que a latência da rede pode tornar-se mais visível quando o percurso inclui repetidores ou outros elementos que introduzem atraso. A pista de diagnóstico consiste em verificar se o arranque ou a recuperação após uma procura pioram antes de o débito sustentado ser afetado.

Meça o tempo até ao primeiro fotograma, a recuperação após uma procura e a reprodução contínua separadamente para o mesmo ficheiro. Se os dois primeiros aumentarem num percurso com maior latência, mas o fluxo permanecer fluido depois de o buffer estar cheio, a latência é o sintoma dominante. Se a reprodução esgotar repetidamente o buffer, também será necessário investigar a entrega sustentada.

Os clientes mistos podem chegar ao servidor através de percursos de rede diferentes

Uma casa pode ter uma televisão ligada por cabo à LAN, um tablet em Wi-Fi atrás de um salto de rede mesh e um telemóvel a aceder ao Plex através da internet. Esses clientes não partilham a mesma latência, perda ou largura de banda, apesar de utilizarem o mesmo servidor multimédia. A concorrência combina, portanto, condições de rede desiguais.

A reprodução direta através de um percurso de armazenamento remoto ou de rede pode ser sensível ao buffer do cliente, porque o comportamento da bufferização com débitos elevados dispõe de menos buffer de conversão no servidor para ocultar variações na entrega. Um único ponto final lento não prova que o servidor esteja sobrecarregado.

Identifique cada sessão pelo percurso, além do modo de reprodução. Se apenas o cliente mesh ficar mais lento enquanto o cliente ligado por cabo permanece saudável, não transforme a média dos dois num problema de latência geral do servidor. Se todos os clientes ficarem mais lentos em conjunto, procure uma ligação partilhada do servidor, uma dependência do armazenamento ou um percurso a montante.

A latência reduz a margem disponível no buffer do cliente

Um buffer transforma pequenos atrasos da rede em pausas invisíveis na chegada dos dados. Uma latência e uma instabilidade superiores consomem essa proteção ao tornar os reabastecimentos menos previsíveis, especialmente quando o débito do ficheiro é irregular ou o cliente mantém um buffer pequeno. Assim, o mesmo débito médio pode ser percecionado de forma diferente em dois percursos.

Um caso de Plex remoto com latência elevada mostra uma reprodução instável mesmo quando a largura de banda indicada parece adequada. Por isso, o streaming com latência elevada deve ser testado com base no comportamento do buffer, e não apenas num número de teste de velocidade.

Observe se o cliente recupera durante cenas calmas e falha durante picos de débito. Se a latência estiver a consumir a margem do buffer, reduzir o débito solicitado pode melhorar a estabilidade sem alterar a capacidade de processamento do servidor. Se a sessão passar a transcodificar depois dessa alteração, separe a correção de rede da nova carga de processamento.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

A concorrência acrescenta filas nas ligações partilhadas

Vários clientes podem aumentar indiretamente a latência ao ocuparem o tempo de transmissão partilhado do Wi-Fi, a fila do router, a ligação ascendente WAN ou a interface do servidor. O atraso adicional pode surgir antes de a ligação atingir um limite simples de utilização, porque as filas e as retransmissões aumentam durante os picos de várias sessões.

A bufferização durante a reprodução direta pode ocorrer quando a rede não consegue entregar os dados com rapidez suficiente, e os limites da reprodução com latência elevada tornam-se mais informativos quando comparados antes e depois de outro cliente iniciar uma sessão. A segunda sessão é uma forma controlada de criar filas.

Inicie um cliente representativo, registe a latência e o débito e, em seguida, adicione o segundo e o terceiro sem alterar os ficheiros. Se o atraso de ida e volta ou a perda de pacotes aumentarem antes de a reprodução piorar, a rede partilhada faz parte do mecanismo de concorrência. Se as métricas de rede permanecerem estáveis, volte a investigar os recursos de armazenamento ou de transcodificação.

Um teste com clientes mistos separa o atraso da rede do trabalho do servidor

A latência deve ser testada enquanto o modo de reprodução do servidor é conhecido. Um cliente que transcodifica introduz atraso de codificação e pode solicitar um débito inferior, enquanto um cliente em Reprodução direta expõe o percurso de entrega de forma mais direta. Compará-los sem identificar o modo mistura causas relacionadas com a rede e com o processamento.

As definições de qualidade do cliente podem alterar o facto de o servidor converter ou não um fluxo, por isso o comportamento da qualidade do cliente deve fazer parte da configuração do teste, em vez de ser alterado a meio. Mantenha o pedido constante enquanto mede o percurso.

Utilize uma sessão local de Reprodução direta, ligada por cabo, como controlo e, em seguida, adicione os clientes remotos e Wi-Fi reais. Acompanhe em conjunto o modo de reprodução, a latência, as perdas, a utilização da ligação do servidor e os sintomas no buffer. Se o tráfego agregado for o fator limitador, o teste da ligação partilhada fornece o próximo ponto de decisão.