Jitter i pèrdua de paquets en una trucada VPN: què cal comparar
La parla tardana però suau i la parla que es trenca en buits són dues fallades diferents. Compareu les estadístiques de la mateixa aplicació, la ràdio local i un camí carregat.
La parla robòtica i les síl·labes perdudes sonen diferent perquè són fallades diferents. El jitter canvia quan arriben els paquets; la pèrdua vol dir que no arriben de cap manera. Totes dues coses poden passar mentre una prova de velocitat informa d’una baixada saludable, perquè el cabal i el lliurament puntual mesuren coses diferents. Feu coincidir les proves amb el so abans de canviar cap paràmetre.
Per què els paquets tardans i els que falten sonen diferent
Els mitjans surten de l’emissor a un ritme constant, i les xarxes reals els lliuren amb espaiats desiguals. Les aplicacions fan una mica de memòria intermèdia per suavitzar-ho, bescanviant retard per continuïtat: pugeu la memòria i la conversa sembla lenta, baixeu-la i apareixen buits. Un paquet que arriba després del seu termini de reproducció està efectivament perdut, encara que mai no s’hagi descartat. Per això dues connexions amb el mateix ample de banda poden produir trucades molt diferents.
La direcció també importa. Els mitjans entrants i sortints poden seguir camins diferents, sobretot quan un costat és en una xarxa mòbil.
Els números que cal llegir durant la finestra dolenta
Useu les estadístiques de la mateixa aplicació quan les ofereix, i llegiu-les mentre la trucada va malament, no quan s’ha acabat. El repetidor de mitjans sovint és un amfitrió diferent del lloc web del servei, així que un ping a la pàgina d’inici mesura un camí que la trucada no fa servir. Mireu el percentatge de pèrdua, el temps d’anada i tornada i el jitter per separat, i anoteu si el client envia o rep el problema. Una reconnexió de VPN durant la trucada és un tercer esdeveniment que cal enregistrar, no fusionar amb els altres.
Les captures de pantalla del panell d’estadístiques són millors que un record de la trucada, perquè els números es poden comparar després. Vint segons de percentatge de pèrdua us diuen si el camí descarta paquets ara, però no si la pèrdua és a ràfegues o quan va començar.
Per això repetiu el mesurament en una segona condició en lloc de llegir una finestra com un veredicte. Dues finestres preses en condicions diferents diuen més que una finestra llarga presa sense cap condició.
Què fa una memòria de jitter amb el termini
Una memòria de jitter reté breument els paquets entrants perquè les arribades desiguals — la variació de retard que RFC 3393 defineix com a mètrica — es puguin reproduir amb un rellotge regular. La mida de la memòria fixa el termini de reproducció: tot paquet més tardà que aquest termini es descarta, sigui quin sigui el contingut. Els còdecs difereixen en quant poden amagar, i un còdec que interpola un fotograma absent pot amagar una pèrdua, però no una sèrie. Per això el mateix percentatge de pèrdua dona qualitat de trucada diferent en còdecs diferents.
Ajustar la memòria és un bescanvi, no una solució. Una memòria més gran compra continuïtat a costa de retard en la conversa, i no pot recuperar paquets que arribin després del termini.
Compareu la ràdio i la càrrega abans de la sortida
Mantingueu la sortida i l’aplicació fixes mentre canvieu una condició local alhora. Una icona de senyal forta no diu res sobre la congestió del canal. Si el problema segueix una habitació o un punt d’accés, la ràdio és la investigació següent.
ping -c 50 -i 0.2 203.0.113.9
mtr -rw -c 20 203.0.113.9
El ping dona un recompte de pèrdues i una dispersió que podeu comparar entre condicions, i mtr mostra la pèrdua per salt al llarg del camí. Els salts intermedis que fallen mentre els posteriors responen normalment donen menys prioritat a ICMP en lloc de descartar el trànsit d’usuari. Repetiu tots dos mentre s’executa una pujada controlada, perquè un enllaç que va bé en repòs i és inutilitzable sota càrrega apunta a la cua d’espera, no a la VPN. Si només una condició reprodueix el problema, l’altra condició acaba de quedar descartada.
Repareu només el que la comparació dona suport
Cada comparació dona suport a una reparació, i aplicar-ne diverses alhora destrueix la prova. Un camí local feble demana un canal millor o Ethernet, el trànsit competidor demana planificació o una disciplina de cua, i una sortida dolenta demana comparar una altra sortida en les mateixes condicions. Quan canvieu el transport de la VPN, manteniu el perfil vàlid i canvieu una variable alhora. Torneu a provar la mateixa conversa amb activitat de fons normal en lloc de jutjar l’èxit per si la puntuació de la prova de velocitat ha pujat.
Anoteu la direcció, la pèrdua, el jitter, el temps d’anada i tornada i la condició en què es va mesurar cada cosa. Aquest registre converteix una queixa vaga sobre la qualitat de la trucada en una troballa sobre la qual algú pot actuar. Guardeu-lo amb el tiquet perquè la comparació següent comenci des de la mateixa línia de base.