Os parámetros que regulan a calidade do servizo (QoS, Quality of Service) en redes se miden cos seguintes KPI (Key Performance Indicators):
Latencia ou retardo: É a cantidade de tempo que lle leva ós paquetes viaxar dun extremo a outro na comunicación. Depende da velocidade da luz no medio, das interferencias, e sobre todo, do número de05 saltos (cambios de rede). Cisco recomenda unha latencia menor de 150 milisegundos para VoIP (menos é mellor). No mercado emerxente dos videoxogos na nube se recomenda menos de 40 ms.
Jitter(Packet delay variation): Non chega con que haxa pouca latencia, esta debería ser constante. Segundo Cisco, debería ser menor de 30 milisegundos. En casos extermos se poderían chegar a escoitar sílabas intercambiadas.
Ancho de banda insuficiente: As aplicacións de VoIP consumen moi pouco ancho de banda. Sen embargo, en situacións de moita ocupación dos canais, sen control de QoS (Quality of Service) nin VLAN que segmenten o tráfico, pode ocurrir que o tráfico máis demandante (vídeo, descargas masivas), provoque que a VoIP non chegue a acadar os kbps de throughput necesarios para unha mínima calidade. Dependendo do códec de audio, o ancho de banda necesario son entre 30 e 64 kbps simétricos xa que a comunicación é bidireccional. Nas redes móbiles o ancho de banda de voz está segmentado para que non falle, pero o ancho de banda de datos se divide concurrentemente: non é o mesmo que a cidade estea baleira, que que haxa unha verbena. As operadoras falan de 5G, 4G, pero nunca dun ancho de banda garantizado.
Perda de paquetes: Debería ser menor do 1 % dos paquetes enviados por unidade de tempo para que non se perciban microcortes nas conversacións de voz.
Medición entre un nodo e “Internet”
Non existe un lugar chamado “Internet”, Internet é unha rede descentralizada. Tes que ter claro que cando realizas un test de ancho de banda, o que fas é comunicarte cun servidor en Oviedo, Porto… sempre un lugar concreto.
Podes medir a latencia co comando ping na terminal de Windows (cmd):
Desde o móbil tamén podes medir o ping coa aplicación Fing (Android | iOS). Antes vimos que a latencia depende do número de saltos. Podes comprobalos co comando traceroute (Linux) ou tracert (Windows).
Lembra que en Windows debes usar o modificador “-t” para que funcione de xeito indefinido.
Medición entro dous nodos coñecidos: throughput, perda de paquetes e jitter
Coñecemento previo: capa 4 (protocolos de transporte):
TCP: (Transport Control Protocol). Orientado á conexión (con acuse de recibo). Navegación web, e-mail… CASE todo.
UDP: (User datagram protocol), NON orientado á conexión (sen acuse de recibo). Só para aplicacións de tempo crítico nas que non importa a perda de información: streaming e VoIP.
Trátase dunha aplicación cliente-servidor. A aplicación CLI soporta tanto o modo servidor (-s) como cliente (-c 192.168.XXX.YYY). Existen aplicacións de cliente para iOS e para Android.
Por defecto, mide o fluxo de datos TCP desde o cliente ata o servidor (subida). Co modificador -R mide no sentido de baixada. Con -u se usa protocolo UDP, no cal mide a maiores perda de paquetes e jitter.
ATENCIÓN: iperf3 limita o ancho de banda nos tests UDP a 1 Mbps. Para sobrepasar ese límite, debes especificar o flag -b e especificar límite. Exemplo: iperf3 -c 192.168.99.18 -b 1000MInfo | Manpage de iperf3 -b
Shadow Speedtest detectando un escalón de 15 ms na latencia, que provoca un impulso no jitter. Como despois a latencia permanece constante, o jitter tende a cero
