La fibra misura 900 Mbit/s.
Il ripetitore riceve perfettamente.
Il segnale RF è eccellente.
Eppure la voce arriva:
- spezzata;
- robotica;
- in ritardo;
- con parole mancanti.
Com’è possibile?
Perché per una rete radio digitale la velocità massima della connessione è spesso molto meno importante della qualità con cui arrivano i singoli pacchetti.
Tre parametri sono particolarmente importanti:
latency
jitter
packet loss
Sono tre concetti differenti e comprenderli permette di diagnosticare gran parte dei problemi audio presenti nelle reti digital voice.
Gli standard IETF dedicati alle applicazioni real-time distinguono chiaramente perdita dei pacchetti e variazione dei tempi di arrivo; RFC 3550, ad esempio, tratta l’interarrival jitter come una misura a breve termine della variazione nel comportamento della rete e osserva che perdita e jitter possono indicare forme differenti di congestione.
1. Latency: quanto impiega un pacchetto?
Immaginiamo:
RIPETITORE A
│
▼
INTERNET
│
▼
SERVER
Un pacchetto parte alle:
10:00:00.000
e arriva alle:
10:00:00.035
Il ritardo one-way è:
35 ms
Questa è la latenza.
Ping e RTT
Quando utilizziamo:
ping server
misuriamo normalmente il:
RTT
ovvero:
Round Trip Time.
Il pacchetto va:
A → B
e la risposta ritorna:
B → A
Se leggiamo:
40 ms
non significa automaticamente:
20 ms + 20 ms
perché il percorso in una direzione può essere diverso dall’altro.
Ma il ping resta un ottimo indicatore iniziale.
La latenza non deve per forza essere bassissima
Una rete con:
50 ms
costanti può funzionare perfettamente.
Una rete con:
5 ms
20 ms
150 ms
10 ms
400 ms
può essere molto più problematica.
Per la voce real-time conta quindi non soltanto:
quanto ritardo abbiamo
ma anche:
quanto è stabile.
Ed eccoci al jitter.
2. Jitter: quando i pacchetti non arrivano con ritmo regolare
Supponiamo che il trasmettitore produca pacchetti ogni 20 ms:
P1 0 ms
P2 20 ms
P3 40 ms
P4 60 ms
P5 80 ms
La rete ideale li consegna:
P1 100 ms
P2 120 ms
P3 140 ms
P4 160 ms
P5 180 ms
Abbiamo latenza:
100 ms
ma perfettamente regolare.
Ora introduciamo jitter
I pacchetti arrivano:
P1 100 ms
P2 122 ms
P3 171 ms
P4 164 ms
P5 181 ms
La latenza cambia continuamente.
Un pacchetto arriva tardi.
Uno magari arriva persino dopo quello successivo.
Questa variazione temporale è ciò che normalmente chiamiamo jitter o packet delay variation.
RFC 3393 sottolinea che il termine “jitter” viene usato con significati differenti e formalizza invece il concetto di variazione del ritardo dei pacchetti IP.
Perché il jitter è un problema per la voce?
L’altoparlante deve riprodurre un flusso regolare.
Non può fare:
audio
audio
...
silenzio
AUDIO VELOCISSIMO
...
silenzio
soltanto perché Internet ha consegnato i pacchetti in maniera irregolare.
Serve quindi un:
jitter buffer.
Il jitter buffer
Il ricevitore aspetta volutamente un piccolo intervallo prima di iniziare la riproduzione.
Per esempio:
PACCHETTI INTERNET
↓
↓
JITTER BUFFER
P1 P2 P3 P4
↓
uscita regolare
↓
AUDIO
Il buffer assorbe piccole variazioni nei tempi di arrivo.
RFC 7657 evidenzia che un riordinamento limitato contenuto all’interno del jitter buffer può essere gestito senza effetti percepibili, mentre pacchetti che arrivano oltre la capacità del buffer possono causare glitch e disturbi.
Buffer enorme? Problema risolto?
No.
Supponiamo di impostare:
jitter buffer = 2 secondi
Avremmo probabilmente grande tolleranza alle variazioni.
Ma ogni QSO avrebbe:
2 secondi
di ulteriore ritardo.
Per una conversazione Push-To-Talk sarebbe fastidiosissimo.
Quindi dobbiamo trovare un compromesso:
buffer piccolo
→ poca latenza
→ poca tolleranza al jitter
buffer grande
→ maggiore tolleranza
→ maggiore latenza
È uno dei classici compromessi delle comunicazioni real-time.
3. Packet loss: il pacchetto non arriva
Ora immaginiamo:
P1 ✓
P2 ✓
P3 X
P4 ✓
P5 ✓
P3 è stato perso.
Questa è:
packet loss.
RFC 3550 prevede proprio metriche per calcolare la frazione di pacchetti persi rispetto a quelli attesi in un intervallo di osservazione.
Perché non chiediamo semplicemente di ritrasmetterlo?
Perché la voce è real-time.
Immaginiamo che P3 appartenga alla sillaba:
“buon…”
Quando il sistema scopre la perdita e ritrasmette il pacchetto, potremmo essere già arrivati alla parola successiva.
Il pacchetto sarebbe corretto ma:
troppo tardi.
RFC 7657 osserva che nelle comunicazioni interattive i dati che arrivano sufficientemente tardi vengono spesso scartati e che la ritrasmissione può diventare controproducente.
Questo spiega perché viene spesso utilizzato UDP
UDP non garantisce:
- consegna;
- ordine;
- ritrasmissione.
Ma proprio per questo evita di fermare il flusso aspettando dati vecchi.
Nelle applicazioni real-time è spesso preferibile:
perdere P3
e continuare con:
P4
piuttosto che bloccare tutto.
Cosa fa il decoder quando manca un pacchetto?
Dipende dal sistema.
Può:
- ripetere informazioni precedenti;
- interpolare;
- generare comfort audio;
- silenziare;
- tentare error concealment.
La famiglia di standard RTCP XR prevede perfino metriche specifiche per indicare periodi nei quali il ricevitore ha dovuto generare audio locale per mascherare pacchetti mancanti o scartati.
Quando la perdita diventa troppo elevata sentiamo:
- pezzi di parola mancanti;
- audio robotico;
- gorgoglii;
- drop;
- silenzi.
Loss e jitter possono sembrare la stessa cosa
Un pacchetto può tecnicamente arrivare.
Ma se arriva:
troppo tardi
il jitter buffer lo scarta.
Dal punto di vista della rete:
packet delivered
dal punto di vista dell’audio:
packet unusable
Per questo le metriche applicative distinguono spesso:
network loss
da:
packet discard
RFC 4710 osserva infatti che perdita di rete e pacchetti scartati dall’applicazione possono avere effetti simili sulla qualità percepita pur avendo cause differenti.
Una connessione a 1 Gbit può fare pessimo digital voice
Supponiamo:
DOWN 940 Mbit/s
UP 500 Mbit/s
ma:
packet loss 3%
jitter 80 ms
Una rete digital voice può funzionare male.
Al contrario:
10 Mbit/s
con:
loss ≈ 0
jitter molto basso
latency stabile
può funzionare magnificamente.
Questo perché la voce digitalizzata utilizza relativamente poca banda, ma necessita di regolarità.
Bandwidth non è quality
È importante distinguere:
BANDWIDTH
da:
QUALITY
Bandwidth significa:
quanti bit possiamo trasportare.
Latency significa:
quanto impiegano.
Jitter significa:
quanto varia quel tempo.
Packet loss significa:
quanti non arrivano utilizzabili.
Sono quattro parametri differenti.
Il bufferbloat
Un problema particolarmente subdolo nasce quando una linea viene saturata.
Scenario:
fibra / LTE
│
├── digital voice
├── backup cloud
└── telecamera
Parte un upload enorme.
Il router mette centinaia di pacchetti in coda.
La banda non è necessariamente persa.
Ma i pacchetti voice devono aspettare.
Risultato:
latency ↑
jitter ↑
Il QSO inizia a degradarsi.
Il test classico
Proviamo:
ping server
senza traffico.
Risultato:
25 ms
26 ms
24 ms
25 ms
Perfetto.
Ora lanciamo un upload importante.
Il ping diventa:
30 ms
70 ms
240 ms
800 ms
350 ms
Questo è un segnale fortissimo di code eccessive.
QoS può aiutare
Se il router distingue:
VOICE
da:
DOWNLOAD
può dare priorità ai pacchetti real-time.
Per esempio:
HIGH PRIORITY
digital voice
VPN management
NORMAL
web
LOW
backup
aggiornamenti
RouterOS permette di classificare e marcare traffico anche attraverso parametri come IP, porta e DSCP.
Ma DSCP non è magia su Internet
Possiamo marcare:
DSCP
all’interno della nostra rete.
Questo può funzionare benissimo:
ripetitore
↓
router locale
↓
WAN
Ma non possiamo pretendere che tutti gli ISP mantengano quella priorità.
RFC 7657 osserva esplicitamente che i valori DSCP possono essere modificati o azzerati ai confini delle reti degli operatori.
Quindi QoS è particolarmente utile sulla nostra parte della rete, soprattutto nel punto di congestione:
LAN → WAN
Il vero collo di bottiglia è spesso l’upload
Una connessione domestica può essere:
1000 Mbit down
100 Mbit up
Se saturiamo:
100 Mbit up
anche la gestione delle code può peggiorare.
Non guardiamo soltanto il download pubblicizzato dall’operatore.
LTE e 5G: il problema della variabilità
Una rete cellulare può passare rapidamente da:
30 ms
a:
150 ms
a causa di:
- congestione;
- scheduling radio;
- cambio cella;
- condizioni RF;
- carico della rete.
Non significa necessariamente che LTE sia inadatto.
Significa che dobbiamo osservare:
la stabilità nel tempo.
Starlink
Lo stesso concetto vale per una rete satellitare.
Il throughput può essere elevato, ma per un sistema real-time interessa soprattutto monitorare:
latency
jitter
loss
outage
e non soltanto:
speed test
Wi-Fi: spesso il problema è dentro casa
Immaginiamo:
Internet perfetto
ma:
Raspberry → Wi-Fi
su un canale congestionato.
Possiamo avere:
retransmission RF
interferenze
collisioni
packet loss
prima ancora che il pacchetto raggiunga il router.
Per una postazione fissa importante preferirei:
Ethernet
quando possibile.
Come diagnostichiamo?
Non iniziamo cambiando dieci configurazioni.
Seguiamo il percorso.
REPEATER
↓
ROUTER
↓
ISP
↓
INTERNET
↓
SERVER
Testiamo ogni tratto.
Test 1: ping
ping IP_SERVER
Osserviamo:
- media;
- minimo;
- massimo;
- packet loss.
Ma soprattutto guardiamo la dispersione.
Esempio buono:
21
22
21
23
22
Esempio sospetto:
20
21
180
23
450
La media da sola potrebbe nascondere il problema.
Test 2: ping continuo
Un test di:
10 secondi
può non mostrare nulla.
Meglio misurare per:
ore
se il problema è intermittente.
Con Prometheus possiamo registrare:
latency
loss
availability
e Grafana può mostrarne l’andamento.
Test 3: confrontiamo i gateway
ping router locale
ping gateway ISP
ping VPS
Se:
router locale = instabile
problema LAN.
Se:
router locale = perfetto
VPS = instabile
problema WAN/percorso.
Test 4: MTR/traceroute
Un traceroute mostra il percorso.
MTR ripete continuamente le misurazioni.
Possiamo osservare:
HOP 1 router
HOP 2 ISP
HOP 3 backbone
HOP 4 server
Ma attenzione: alcuni router limitano o deprioritizzano ICMP, quindi una perdita apparente su un hop intermedio non significa automaticamente perdita del traffico reale.
La cosa più importante è ciò che osserviamo alla destinazione finale.
Test 5: iperf3 UDP
Se controlliamo entrambi gli endpoint possiamo utilizzare iperf3.
Il progetto ufficiale supporta test:
TCP
UDP
SCTP
e la modalità UDP viene attivata con:
iperf3 -c SERVER -u
La documentazione corrente di iperf3 descrive anche bitrate, test inversi e bidirezionali.
Esempio:
iperf3 -s
sul server.
Sul sito:
iperf3 -c 10.0.0.1 -u -b 500K -t 60
Non serve necessariamente sparare 100 Mbit/s.
Per simulare un’applicazione radio è spesso più interessante usare un bitrate realistico e osservare stabilità e perdita.
Testare entrambe le direzioni
Problema frequente:
SITE → SERVER perfetto
ma:
SERVER → SITE pessimo
Con iperf3 possiamo invertire la direzione tramite:
-R
oppure usare test bidirezionali nelle versioni che supportano l’opzione dedicata.
Monitoring reale
Per ogni ripetitore registrerei almeno:
WAN UP/DOWN
RTT
packet loss
jitter o delay variation
VPN status
Una dashboard potrebbe mostrare:
RPTR TORTONA
RTT AVG 32 ms
RTT MAX 51 ms
LOSS 0.0 %
JITTER LOW
VPN UP
WAN STARLINK
Gli spike contano più della media
Supponiamo:
media = 35 ms
Sembra ottimo.
Ma se ogni minuto abbiamo:
1500 ms
per due pacchetti, l’audio può comunque avere drop percepibili.
Quindi registrerei:
- median;
- percentile;
- max;
- loss.
Non soltanto average.
Baseline
Ogni sito ha caratteristiche differenti.
Prima registriamo una condizione sana.
Per esempio:
RTT normale: 25–35 ms
loss normale: 0 %
Se improvvisamente vediamo:
RTT: 80–200 ms
loss: 2 %
abbiamo un’indicazione concreta.
CISA, anche in ambito di sicurezza e network monitoring, raccomanda di stabilire baseline del normale comportamento della rete proprio per poter individuare anomalie.
Quando il problema è il server
Non sempre il problema è Internet.
Il reflector può avere:
CPU 100%
RAM esaurita
NIC congestionata
processo bloccato
Il risultato percepito può assomigliare a packet loss di rete.
Quindi monitoriamo anche:
CPU
load
network queue
RAM
process
Quando il problema è il transcoder
Nei bridge multiprotocollo:
DMR
↓
TRANSCODER
↓
YSF
un carico eccessivo può produrre:
- buffering;
- frame in ritardo;
- latenza;
- drop.
Il percorso va quindi analizzato end-to-end.
Una semplice metodologia diagnostica
Se l’audio è pessimo:
STEP 1
RF OK?
Controlliamo BER, RSSI, modulazione.
STEP 2
LAN OK?
Ping router.
STEP 3
WAN OK?
Ping server.
STEP 4
LOSS?
Test prolungato.
STEP 5
JITTER?
Osserviamo variazioni temporali.
STEP 6
SERVER OK?
CPU e network.
STEP 7
TRANSCODER?
Controlliamo buffering e carico.
Questo evita di attribuire a Internet un problema che in realtà nasce dalla RF.
Le tre firme tipiche
Alta latency ma stabile
250
251
249
252
Audio probabilmente regolare ma QSO molto ritardato.
Bassa media, jitter elevato
20
22
180
19
450
21
Audio con possibile instabilità e buffer stressato.
Packet loss
20 ms
21 ms
TIMEOUT
22 ms
TIMEOUT
20 ms
Possibili sillabe mancanti e drop.
Il caso peggiore
latency alta
+
jitter alto
+
loss
In quel caso il jitter buffer deve crescere.
Crescendo aumenta la latenza.
Se comunque i pacchetti arrivano troppo tardi, vengono scartati.
La qualità precipita.
La soluzione non è sempre “più banda”
Se il problema è:
jitter
passare da:
100 Mbit
a:
1 Gbit
può non cambiare nulla.
Se invece la causa è saturazione del link, aumentare la banda può aiutare indirettamente.
Prima bisogna conoscere la causa.
Cosa fare concretamente
Per una postazione remota:
Ethernet dove possibile
router serio
QoS sulla WAN
monitoring permanente
dual-WAN
VPN stabile
Per il traffico real-time:
priorità
code controllate
niente saturazione prolungata
Per i server:
monitor CPU
monitor NIC
monitor loss
Una regola importante
Non giudicate una connessione con:
Speedtest: 500 Mbps
Giudicatela con:
Come si comportano i pacchetti durante tutto il giorno?
Per una rete radio digitale questa è la domanda giusta.
Conclusioni
Latency, jitter e packet loss descrivono tre problemi differenti:
LATENCY
= quanto tempo impiega il pacchetto
JITTER
= quanto varia quel tempo
PACKET LOSS
= quanti pacchetti non arrivano utilizzabili
La banda ci dice invece:
quanti dati possiamo trasmettere
Per la voce digitalizzata, una connessione:
20 Mbit/s
stabile
può essere migliore di:
1 Gbit/s
instabile
Ecco perché un buon Sysop non dovrebbe guardare soltanto:
DOWNLOAD / UPLOAD
ma monitorare continuamente:
LATENCY
JITTER
LOSS
Sono questi tre parametri che spesso determinano se una rete digitale sembra una vera infrastruttura di telecomunicazioni oppure una conversazione robotica che perde una parola ogni tre.
In una rete ben progettata, il pacchetto non deve soltanto arrivare.
Deve arrivare nel momento giusto.