Jitter e perdita di pacchetti in una chiamata VPN: cosa confrontare

Il parlato robotico e le sillabe perse suonano diversi perché sono guasti diversi. Il jitter cambia quando arrivano i pacchetti; la perdita significa che non arrivano affatto. Entrambi possono accadere mentre un test di velocità riporta un download sano, perché la capacità e la consegna puntuale misurano cose diverse. Fate corrispondere le prove al suono prima di cambiare qualsiasi impostazione.

Perché i pacchetti in ritardo e quelli mancanti suonano diversi

I media lasciano il mittente a ritmo costante, e le reti reali li consegnano con spaziature irregolari. Le applicazioni ne bufferizzano un po’ per levigare la cosa, scambiando ritardo con continuità: alzate il buffer e la conversazione sembra lenta, abbassatelo e compaiono vuoti. Un pacchetto che arriva dopo la sua scadenza di riproduzione è di fatto perso, anche se non è mai stato scartato. Per questo due connessioni con la stessa banda possono produrre chiamate molto diverse.

Anche la direzione conta. I media in entrata e in uscita possono seguire percorsi diversi, soprattutto quando un lato è su una rete mobile.

I numeri da leggere durante la finestra cattiva

Usate le statistiche dell’applicazione stessa dove le offre, e leggetele mentre la chiamata va male, non dopo la fine. Un relè media è spesso un host diverso dal sito del servizio, quindi un ping alla pagina iniziale misura un percorso che la chiamata non usa. Guardate la percentuale di perdita, il tempo di andata e ritorno e il jitter separatamente, e annotate se il client invia o riceve il problema. Una riconnessione VPN durante la chiamata è un terzo evento da registrare, non da fondere con gli altri.

Gli screenshot del pannello delle statistiche valgono più di un ricordo della chiamata, perché i numeri si possono confrontare dopo. Venti secondi di percentuale di perdita vi dicono se il percorso sta scartando pacchetti ora, ma non se la perdita è a raffiche o quando è iniziata.

Per questo ripetete la misura in una seconda condizione invece di leggere una finestra come verdetto. Due finestre prese in condizioni diverse dicono più di una finestra lunga presa senza alcuna condizione.

Che cosa fa un buffer di jitter alla scadenza

Un buffer di jitter trattiene brevemente i pacchetti in arrivo perché gli arrivi irregolari — la variazione di ritardo che RFC 3393 definisce come metrica — possano essere riprodotti su un orologio regolare. La dimensione del buffer fissa la scadenza di riproduzione: ogni pacchetto più tardi di quella scadenza viene scartato, qualunque sia il contenuto. I codec differiscono in quanto riescono a mascherare, e un codec che interpola un frame mancante può nascondere una perdita ma non una serie. Per questo la stessa percentuale di perdita dà qualità di chiamata diversa su codec diversi.

Regolare il buffer è uno scambio, non una correzione. Un buffer più grande compra continuità al costo del ritardo nella conversazione, e non può recuperare i pacchetti che arrivano dopo la scadenza.

Confrontate la radio e il carico prima dell’uscita

Tenete fissi l’uscita e l’applicazione mentre cambiate una condizione locale alla volta. Un’icona di segnale forte non dice nulla sulla congestione del canale. Se il problema segue una stanza o un punto di accesso, la radio è l’indagine successiva.

ping -c 50 -i 0.2 203.0.113.9
mtr -rw -c 20 203.0.113.9

ping dà un conteggio delle perdite e una dispersione che potete confrontare tra condizioni, e mtr mostra la perdita per salto lungo il percorso. I salti intermedi che falliscono mentre i successivi rispondono di solito abbassano la priorità di ICMP invece di scartare il traffico utente. Ripetete entrambi mentre gira un caricamento controllato, perché un collegamento buono a riposo e inutilizzabile sotto carico indica l’accodamento, non la VPN. Se solo una condizione riproduce il problema, l’altra condizione è appena stata esclusa.

Riparate solo ciò che il confronto sostiene

Ogni confronto sostiene una riparazione, e applicarne diverse insieme distrugge la prova. Un percorso locale debole richiede un canale migliore o Ethernet, il traffico concorrente richiede pianificazione o una disciplina di coda, e un’uscita cattiva richiede di confrontare un’altra uscita nelle stesse condizioni. Quando cambiate il trasporto della VPN, mantenete valido il profilo e cambiate una variabile alla volta. Provate di nuovo la stessa conversazione con attività di fondo normale invece di giudicare il successo dalla salita di un punteggio del test di velocità.

Annotate direzione, perdita, jitter, tempo di andata e ritorno e la condizione in cui ciascuno è stato misurato. Quel verbale trasforma un reclamo vago sulla qualità della chiamata in un riscontro su cui qualcuno può agire. Tenetelo con il ticket perché il confronto successivo parta dalla stessa base.