Che cos’è il bufferbloat e perché conta più della sola velocità?

Il bufferbloat è l’aumento del ritardo causato da pacchetti che rimangono troppo a lungo nelle code di un apparato o di un collegamento congestionato. In pratica, una linea può scaricare file rapidamente ma diventare meno reattiva appena qualcuno avvia un backup, un download o una sincronizzazione cloud.

Durante una videochiamata, una partita online o una sessione di lavoro da remoto, il problema non è soltanto quanti megabit al secondo abbiamo: contano anche la latenza (il ritardo di risposta) e il jitter (quanto varia tale ritardo).

CAKE e fq_codel: cosa cambia?

CAKE integra funzioni di gestione intelligente delle code, fairness e shaping, con l’obiettivo di ridurre i ritardi quando la linea è occupata. fq_codel combina accodamento equo e controllo del ritardo; nel Flint 4 è disponibile come alternativa a CAKE nella voce Queue Rule. Per capire quale sia più efficace sulla nostra rete, li abbiamo provati entrambi con gli stessi limiti di banda.

Come abbiamo eseguito i test sul GL.iNet Flint 4

Il Flint 4 era collegato a un Keenetic che gestiva la linea FTTC Dimensione. Il desktop ASUS utilizzava una connessione Ethernet negoziata a 2,5 Gbit/s verso il Flint 4: ampiamente sufficiente per una FTTC da circa 158 Mbps. Per il confronto abbiamo disattivato il controllo della banda sul Keenetic, evitando che alterasse il comportamento delle code prima del Flint 4.

Sono state conservate le schermate complete dei tre scenari. Per ogni scenario qui riportiamo una singola misurazione: le differenze vanno intese come risultati osservati in questa sessione, non come intervalli statistici né prestazioni garantite per qualsiasi connessione.

Test 1 — Flint 4 con SQM disattivato

Per prima cosa abbiamo misurato la situazione senza gestione delle code da parte del Flint 4. La linea ha raggiunto 158 Mbps in download e 19 Mbps in upload, con una latenza a riposo di 22,9 ms.

Quando il test ha impegnato l’upload, la latenza riportata da Cloudflare è salita a 41,7 ms e il jitter a 37,1 ms. Il comportamento in download è stato invece meno critico: 26,1 ms di latenza e 7,6 ms di jitter sotto carico.

Test 2 — SQM con CAKE: la latenza in upload torna stabile

Abbiamo attivato SQM con Queue Rule impostata su CAKE, configurando 145 Mbps in download e 17 Mbps in upload. Sono soglie scelte volontariamente al di sotto della banda effettiva, per lasciare al Flint 4 margine di intervento sulla congestione.

Il throughput è passato a 131 Mbps in download e 15,6 Mbps in upload. La latenza a riposo è rimasta quasi invariata (22,7 ms), mentre quella durante l’upload è scesa da 41,7 a 22,4 ms. Ancora più marcato il miglioramento del jitter in upload: da 37,1 a 1,66 ms, una riduzione del 95,5% nella nostra prova.

Test 3 — SQM con fq_codel: prestazioni vicine a CAKE

Abbiamo ripetuto il benchmark cambiando soltanto la Queue Rule in fq_codel, lasciando invariati i limiti a 145/17 Mbps. In questo modo i due algoritmi vengono confrontati nelle stesse condizioni di shaping.

Il risultato è stato 132 Mbps in download e 15,5 Mbps in upload, quindi praticamente sovrapponibile a CAKE sul fronte della velocità. La latenza durante l’upload è stata di 23,3 ms e il jitter di 4,29 ms: un miglioramento rilevante rispetto alla situazione senza SQM, anche se nella singola prova CAKE ha registrato valori migliori.

Tutti i risultati a confronto: velocità, ping e jitter

Grafici realizzati in HTML/CSS, non immagini: sono responsive anche su smartphone. I valori di latenza e jitter sotto carico sono quelli mostrati nel riepilogo Cloudflare, non i valori massimi istantanei né una misura continua del ping.

Il confronto mette in evidenza il compromesso: rispetto alla sessione senza SQM, CAKE ha ridotto la velocità misurata del 17,1% in download e del 17,9% in upload, ma ha portato il jitter sotto upload da 37,1 a 1,66 ms. fq_codel ha ottenuto un risultato complessivamente simile, con jitter sotto upload di 4,29 ms.

Perché abbiamo scelto proprio 145/17 Mbps? Non è il limite del router

Questa è una precisazione essenziale: abbiamo volutamente impostato il limite a 145 Mbps in download e 17 Mbps in upload, pur avendo misurato 158/19 Mbps senza SQM. Non significa che il Flint 4 possa raggiungere soltanto 131–132 Mbps quando CAKE o fq_codel sono attivi.

Abbiamo scelto una configurazione iniziale prudente per osservare chiaramente la capacità degli algoritmi di tenere sotto controllo le code. I limiti hanno un effetto diretto sul throughput, perciò i risultati di velocità non rappresentano il massimo ottenibile con una taratura più aggressiva.

La regolazione ottimale dipende dalla velocità realmente disponibile, dalle sue oscillazioni, dai buffer del modem e dell’accesso FTTC, dall’eventuale router a monte e dal traffico degli altri dispositivi. 145/17 Mbps è quindi la nostra configurazione sperimentale, non un valore da copiare automaticamente.

SQM e QoS non sono la stessa cosa: le priorità del Flint 4

Nel firmware 4.9.2 il Flint 4 offre anche la funzione QoS (Beta). A differenza di SQM, che permette di scegliere la disciplina delle code, il QoS propone profili per favorire determinate categorie di applicazioni, tra cui Meeting Priority, Gaming Priority, Web Browsing Priority e Video Streaming Priority; è inoltre disponibile la personalizzazione delle priorità.

Questa schermata documenta le opzioni disponibili, non un benchmark che ne dimostri l’efficacia. Non abbiamo eseguito una comparazione ripetibile della priorità tra due applicazioni sotto congestione; pertanto non attribuiamo al QoS miglioramenti non misurati.

Come configurare SQM sul Flint 4: procedura pratica

Per la configurazione e le limitazioni ufficiali puoi consultare la documentazione GL.iNet dedicata a SQM.