Una connessione può essere veloce e, allo stesso tempo, diventare lenta e poco reattiva appena parte un download o un upload. Abbiamo misurato il fenomeno sulla nostra FTTC Dimensione e ottimizzato SQM su Keenetic Titan SE fino a ottenere appena +6 ms in download e +0 ms in upload nel test Waveform.
Cos’è il bufferbloat?
Il bufferbloat è un aumento eccessivo della latenza quando una connessione viene saturata. In pratica, i pacchetti iniziano ad accumularsi in code troppo lunghe all’interno del router, del modem o della rete dell’operatore e devono aspettare prima di essere trasmessi.
Il risultato è controintuitivo: lo Speedtest può continuare a mostrare una buona velocità, ma durante un upload, un download pesante o una sincronizzazione cloud il ping può salire moltissimo. Navigazione, gaming e chiamate devono quindi condividere la connessione con una coda già piena.
Ping e input possono diventare irregolari mentre qualcuno utilizza intensamente la linea.
Audio e video possono diventare meno stabili quando upload e download sono saturi.
L’upload è spesso il punto più critico sulle FTTC, perché la banda disponibile è molto inferiore al download.
Come capire se il problema è il bufferbloat
Un indizio tipico è una connessione perfettamente reattiva quando non sta succedendo nulla, ma improvvisamente lenta quando qualcuno avvia un download, carica file, fa backup o usa applicazioni che occupano tutta la banda disponibile.
Nel nostro primo test Waveform l’upload aggiungeva 76 ms alla latenza di base.
Dopo l’ottimizzazione SQM, nello stesso tipo di test l’upload non ha aggiunto latenza misurabile.
Come misurare il bufferbloat
Per questa guida abbiamo utilizzato il Waveform Bufferbloat Test. Il test misura prima la latenza della linea senza traffico importante e poi ripete la misura mentre download e upload vengono portati sotto carico.
È il riferimento di partenza: nel nostro caso circa 20–23 ms.
Indica quanti millisecondi vengono aggiunti quando il download è saturo.
Misura l’aumento di latenza mentre l’upload utilizza tutta la banda disponibile.
È utile per orientarsi, ma i millisecondi reali sono più importanti della sola lettera.
Il nostro test iniziale: grado C e upload molto sensibile
Prima dell’ottimizzazione, Waveform ha assegnato alla linea un grado C. La latenza a riposo era di 23 ms, mentre il download aggiungeva 15 ms e l’upload ben 76 ms.
Latenza di riferimento senza saturare la linea.
Aumento durante il download.
Il punto più debole del test iniziale.
Velocità rilevata in questo specifico run.
La linea usata per il test
Le prove sono state eseguite su una FTTC Dimensione VDSL2 35b collegata direttamente al modem DSL del Keenetic Titan SE. La portante può variare nel tempo in base a diafonia e condizioni della linea, quindi i numeri riportati in questa guida descrivono il nostro collegamento reale.
La soluzione: SQM in IntelliQoS
Nel Titan SE la gestione intelligente delle code si trova nella sezione IntelliQoS. La parte che ci interessa è Gestione intelligente delle code (SQM).
L’obiettivo non è rendere la connessione più veloce. Al contrario, SQM crea intenzionalmente un limite leggermente inferiore alla capacità reale della linea, in modo che sia il router a controllare la coda prima che si riempia in un punto della rete sul quale non abbiamo controllo.
Dove si configura
Accedi all’interfaccia web del Titan SE.
Qui trovi classificazione, priorità applicazioni e gestione SQM.
Nel nostro caso Dimensione (Ultra Internet FTTC), linea DSL / PPPoE.
Usa valori leggermente inferiori alla velocità reale misurata, non semplicemente la portante teorica.
Confronta latenza sotto carico e throughput, quindi regola nuovamente se necessario.
Primo tentativo: SQM a 181/19 Mbit/s
Nel primo esperimento abbiamo configurato SQM con 181 Mbit/s in download e 19 Mbit/s in upload. L’effetto sull’upload è stato immediato: Waveform è passato a grado A e l’aumento di latenza in upload è sceso fino a +0 ms.
Il risultato ci ha fatto notare una cosa interessante. In download la nostra linea raggiunge realmente circa 160–164 Mbit/s, quindi impostare un tetto di 181 Mbit/s significa lasciare il limite SQM al di sopra della velocità realmente ottenibile. In pratica, il download continua a poter saturare un punto a monte del router.
Ottimizzazione finale: 155/18 Mbit/s
Abbiamo quindi ridotto il limite a 155 Mbit/s in download e 18 Mbit/s in upload. In questo modo lasciamo un piccolo margine rispetto alla velocità massima reale della FTTC.
Confronto dei tre test
| Configurazione | Unloaded | Download Active | Upload Active | Velocità rilevata | Waveform |
|---|---|---|---|---|---|
| Senza ottimizzazione SQM | 23 ms | +15 ms | +76 ms | 110,8 / 18,7 Mbit/s | C |
| SQM 181 / 19 | 20 ms | +22 ms | +0 ms | 163,2 / 18,0 Mbit/s | A |
| SQM 155 / 18 | 22 ms | +6 ms | +0 ms | 152,0 / 17,2 Mbit/s | A |
Cosa abbiamo guadagnato davvero?
Il punto non è soltanto essere passati da C ad A. Il cambiamento più importante è che la latenza in upload sotto carico è passata da +76 ms a +0 ms nel test Waveform, mentre con il profilo 155/18 anche il download è sceso ad appena +6 ms.
In cambio abbiamo scelto di non utilizzare fino all’ultimo megabit disponibile. È un compromesso intenzionale: rinunciare a una piccola parte del throughput massimo per mantenere la connessione molto più reattiva quando più attività avvengono contemporaneamente.
Quali valori SQM impostare sulla propria linea?
I valori 155/18 funzionano bene sulla nostra FTTC, ma non sono numeri universali. Ogni linea ha una velocità effettiva diversa e può variare nel tempo. Copiare alla cieca i nostri valori non è il modo corretto di usare SQM.
Fai alcuni test in condizioni stabili e prendi come riferimento una velocità realmente raggiungibile.
Come punto di partenza puoi provare un valore nell’ordine del 90–95% della velocità reale, poi verificare il risultato.
Una direzione può essere già ottimale mentre l’altra richiede più margine.
Il valore migliore è quello che mantiene bassa la latenza senza ridurre inutilmente la banda.
SQM e priorità applicazioni non sono la stessa cosa
Nella schermata IntelliQoS il Titan SE offre anche Classificazione applicazione e Priorità delle applicazioni. Queste funzioni servono a riconoscere e dare precedenza a categorie di traffico come chiamate, gaming, streaming o navigazione.
Per isolare l’effetto sulla latenza, i risultati mostrati in questa guida sono centrati sulla parte SQM. Prima conviene sistemare la gestione delle code; solo dopo, se serve, si può lavorare sulla priorità delle applicazioni.
Cosa cambia nell’uso quotidiano?
Un download o un backup in corso ha meno possibilità di far impennare il ping.
La voce e il video competono meno con le grandi code create da trasferimenti pesanti.
La connessione tende a rimanere più reattiva quando più dispositivi lavorano insieme.
Domande frequenti su bufferbloat e SQM
Cos’è il bufferbloat in parole semplici?
È l’aumento della latenza causato da code di pacchetti troppo lunghe quando download o upload saturano la connessione.
SQM aumenta la velocità Internet?
No. In genere limita leggermente il throughput massimo per mantenere sotto controllo le code e ridurre la latenza sotto carico.
Perché 181 Mbit/s non migliorava abbastanza il download?
Sulla nostra linea la velocità reale era inferiore a 181 Mbit/s. Il test suggerisce quindi che quel limite non rendeva il router il collo di bottiglia controllato in download. Abbassandolo a 155 Mbit/s abbiamo ottenuto +6 ms sotto carico.
Devo usare anch’io 155/18?
No. Sono valori specifici della nostra FTTC. Bisogna partire dalla velocità reale della propria linea e trovare il compromesso migliore con test ripetuti.
Il voto A di Waveform significa che la linea è perfetta?
No. È una sintesi utile, ma conviene guardare sempre i millisecondi aggiunti in download e upload e valutare il risultato nel proprio uso reale.
Conclusioni: pochi Mbit/s in meno, molta più reattività
Questo test mostra bene perché il bufferbloat è facile da ignorare: una connessione può sembrare veloce finché non viene messa sotto carico. Nel nostro caso l’upload aggiungeva inizialmente 76 ms alla latenza.
Con SQM sul Keenetic Titan SE siamo prima arrivati a +0 ms in upload e, regolando meglio il limite di download, a soli +6 ms in download. Il profilo 155/18 Mbit/s è risultato il miglior compromesso trovato finora sulla nostra FTTC.
La lezione più importante è semplice: non basta attivare SQM. Bisogna misurare la velocità reale, lasciare un piccolo margine e ripetere i test fino a trovare il punto in cui la latenza scende senza sacrificare inutilmente il throughput.
Leggi la recensione completa del Keenetic Titan SE → Visita il sito ufficiale Keenetic →