Un laborator de bufferbloat nu trebuie să fie spectaculos, ci controlat. Ideea este simplă: creezi o legătură unde uploadul poate fi saturat în mod repetabil, pornești trafic greu într-o direcție și urmărești ce se întâmplă cu latența traficului mic, cum ar fi pingul sau o conexiune interactivă. Dacă latența explodează când se umple coada, ai bufferbloat; dacă rămâne stabilă, algoritmul de coadă își face treaba.
Pentru utilizatorii Linux avansați, comparația CAKE versus FQ-CoDel este interesantă tocmai pentru că ambele vin din aceeași familie de soluții moderne împotriva cozilor umflate, dar nu au aceeași filozofie. FQ-CoDel combină fair queuing cu CoDel, separă fluxurile și încearcă să țină sub control întârzierea în fiecare coadă. CAKE merge mai departe: include shaping integrat, compensare de overhead, opțiuni de izolare a fluxurilor și moduri pentru DiffServ. Pe scurt, FQ-CoDel este o piesă importantă a mecanismului, CAKE este mai aproape de un pachet complet pentru marginea rețelei.
Laboratorul ar trebui să fie izolat de rețeaua de producție. O variantă curată are trei roluri: un client Linux, un router Linux de test și un server de măsurare. Clientul trimite trafic prin router către server. Routerul este locul unde schimbi qdisc-ul: întâi o configurație de bază, apoi FQ-CoDel, apoi CAKE. Nu testa direct pe conexiunea firmei în timpul programului și nu amesteca rezultatele cu trafic necunoscut din casă sau birou.
Primul pas este să afli capacitatea reală de upload a legăturii testate. Apoi setezi shapingul puțin sub această valoare, pentru ca Linux să controleze coada înainte ca ea să se mute în modem, ONT sau alt echipament mai greu de observat. Nu există un procent universal corect pentru toate conexiunile, iar articolul nu inventează unul. Regula practică este să cobori treptat până când testul devine stabil și repetabil.
Al doilea pas este să definești scenariul de măsurare. Ai nevoie de un test de latență fără încărcare, apoi de același test în timp ce uploadul este saturat. Flent este util pentru acest tip de laborator, deoarece rulează teste predefinite, agregă datele și poate produce grafice. Poți folosi și instrumente separate, dar păstrează aceeași metodă la toate rundele: aceeași rută, aceeași durată, același server, aceleași setări.
Pentru FQ-CoDel, urmărești dacă fluxurile concurente sunt tratate echitabil și dacă latența rămâne sub control când traficul mare împinge coada. Documentația Linux descrie FQ-CoDel ca o combinație între Fair Queuing și CoDel, cu parametri precum target, interval, ECN și limite de memorie. Pentru un laborator comparativ, nu începe prin a modifica toți parametrii. Testează întâi comportamentul standard, apoi schimbă câte un singur element.
Pentru CAKE, punctul central este shapingul. Documentația tc-cake menționează opțiuni pentru bandwidth, compensarea overheadului, RTT, izolarea fluxurilor și NAT. Într-un laborator casnic sau de mic birou, CAKE poate fi mai ușor de evaluat pentru că include mai multe decizii într-un singur qdisc. Asta nu îl face automat „mai bun” în orice scenariu, dar îl face foarte potrivit pentru testele de margine WAN, unde uploadul limitat provoacă frecvent latență mare.
Comparația corectă nu se face după o singură rulare. Rulează fiecare variantă de mai multe ori și notează latența de bază, latența sub upload saturat, variația latenței și pierderile, dacă apar. Bufferbloat.net avertizează că benchmarkingul poate fi compromis de capcane hardware și software, inclusiv de offload-uri ale plăcilor de rețea. De aceea, schimbările din laborator trebuie documentate: kernel, placă de rețea, driver, qdisc, lățime de bandă setată și instrumente folosite.
Rezultatul util nu este o medalie acordată dinainte. Dacă FQ-CoDel ține latența suficient de jos într-un scenariu simplu, poate fi alegerea potrivită. Dacă ai nevoie de shaping coerent, compensare de overhead și izolare mai sofisticată la marginea conexiunii, CAKE merită testat serios. Important este să măsori în propriul laborator, nu să copiezi concluzii dintr-o rețea complet diferită.
