Mírně vyšší odezva při vytížení internetu

[Slamb]

@r2d2no ale s tak nízkou rychlostí nedokáže zahltit gigabitový porty na zařízení, tak k tomu ani docházet nemůže 🤔 to je stejnej efekt, jako by si ručně na gigabitu nastavil rychlost o pár Mb/s nižší

[r2d2]

@quadra2030Já taky sice nehraji, ale zvýšení latence o několik desítek ms při práci poznám při zatížení linky. Může se jednat samozřejmě o problém u mé přípojky, příp. VF zde v ČR, těžko říct. VF je jediná přípojka, kde jsem nebyl schopen A+ dosáhnout.

Problémy DOCSIS a latence jsou však dobře známé - viz např. whitepaper Cablelabs - "Low Latency DOCSIS: Technology Overview"
 

                                   When Idle    Under Load  99th Percentile
DOCSIS 3.0 Early Equipment            ~10 ms    ~1000 ms    ~1000 ms
DOCSIS 3.0 w/ Buffer Control          ~10 ms    ~100 ms     ~100 ms
DOCSIS 3.1 Active Queue Management    ~10 ms    ~10 ms      ~100 ms
Low Latency DOCSIS 3.1                ~1 ms     ~1 ms       ~1 ms

 

DOCSIS 3.1 AQM je právě DOCSIS-PIE, o kterém jsem mluvil. A nejedná se jen o technologie u modemů, ale i u CMTS.

@SlambJedná se o situace, kdy je na síti více zařízení, příp. uživatelů samozřejmě. Stačí např. pracovat na vzdálené ploše a na jiném zařízení se začnou stahovat aktualizace. Naštěstí to není tak tragické a časté na 1Gbps lince (proto ji mám konec konců).

[DiDiDi]

Já mám 50mbit upload (shapuju si pouze upload) a používám linuxový router (Turris Omnia s OpenWrt) s cake qdisc:

Citovat

tc qdisc replace dev eth2 root cake bandwidth 52480kbit diffserv4 docsis

K těm 52480 kbit jsem došel pečivou detekcí bufferbloatu (zahltil jsem pomocí traffic generatoru z jedné veřejné IP na druhou upload a následně se pingoval s vyšší DSCP prioritou - s bufferbloatem by latence postupně stoupala).

Bufferbloat samotný JE na straně klienta řešitelný problém, je-li stabilní rychlost uploadu (což u kabelového VF je, aspoň u mě). Všechno ostatní, zejména jitter, ne.

Download neshapuju, tj. zahlcení downloadu je možné, ale to se mi při poměru DL:UL 20:1 skoro neděje...

S nějakou prioritizací (používám modifikaci cake, která mění poměr jednotlivých front voice/video/standard/bulk, bohužel cake je v tomto nekonfigurovatelný, tj. musím patchovat přímo linuxový kernel) packetů je pak v pohodě možné mít plně vytížený upload uploadem do cloudu / torrentem a u toho bez vlivu na latenci hrát hry.

[zajdee]

@DiDiDibyl by pls. link na tu modifikaci cake? Diky.

[r2d2]

@DiDiDiA download jste nezkoušel ? S uploadem jsem taky neměl problém (+1-2ms), ale ten download je špatný u VF u mě (+10 - 15 ms podle toho jak agresivně se shapuje). Zkoušel jsem to s různými routery, jak FQ Codel, tak Cake na OpenWRT, výsledek stejný a navíc mám celkem vysoký jitter i bez zatížení. Nijak extra mě to netrápí, není to rozhodně kritická hodnota, ale spíše by mě to zajímalo zda je to jen nějaký lokální problém, nebo ne.

[DiDiDi]

@zajdee

--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -2462,18 +2462,18 @@ static int cake_config_diffserv4(struct Qdisc *sch)
 	/* class characteristics */
 	cake_set_rate(&q->tins[0], rate, mtu,
 		      us_to_ns(q->target), us_to_ns(q->interval));
-	cake_set_rate(&q->tins[1], rate >> 4, mtu,
+	cake_set_rate(&q->tins[1], rate >> 6, mtu,
 		      us_to_ns(q->target), us_to_ns(q->interval));
-	cake_set_rate(&q->tins[2], rate >> 1, mtu,
+	cake_set_rate(&q->tins[2], rate * 29 / 32, mtu,
 		      us_to_ns(q->target), us_to_ns(q->interval));
-	cake_set_rate(&q->tins[3], rate >> 2, mtu,
+	cake_set_rate(&q->tins[3], rate >> 4, mtu,
 		      us_to_ns(q->target), us_to_ns(q->interval));
 
 	/* bandwidth-sharing weights */
 	q->tins[0].tin_quantum = quantum;
-	q->tins[1].tin_quantum = quantum >> 4;
-	q->tins[2].tin_quantum = quantum >> 1;
-	q->tins[3].tin_quantum = quantum >> 2;
+	q->tins[1].tin_quantum = quantum >> 6;
+	q->tins[2].tin_quantum = quantum * 29 / 32;
+	q->tins[3].tin_quantum = quantum >> 4;
 
 	return 0;
 }
@@ -2713,7 +2713,7 @@ static int cake_init(struct Qdisc *sch, struct nlattr *opt,
 	q->rate_bps = 0; /* unlimited by default */
 
 	q->interval = 100000; /* 100ms default */
-	q->target   =   5000; /* 5ms: codel RFC argues
+	q->target   =  10000; /* 5ms: codel RFC argues
 			       * for 5 to 10% of interval
 			       */
 	q->rate_flags |= CAKE_FLAG_SPLIT_GSO;
-- 
2.43.0

Nedělám žádné zásadní úpravy, jen měním poměry jednotlivých front tak, aby Voice měl 1/16, Video 29/32 a Bulk 1/64 celkového bandwidth uploadu - změna se projeví, jen pokud se použije diffserv4 (default je diffserv3, tj. jen 3 fronty, na tom tento patch nemění nic). Můj usecase je zejména streamování her přes Moonlight/Sunshine a PS Remote Play, proto to nafouknutí Video fronty. Taky jsem zdvojnásobil target, už si moc nepamatuji proč, tahle část možná není potřeba. Další část skládačky je samozřejmě správně prioritizovat packety pomocí DSCP - některé aplikace to umí přímo samy (např. VoWiFi na mém Samsungu se samo označuje a automaticky padá do Voice fronty, jak by mělo), jde to dělat na úrovni routeru ve firewallu/Xtables (např. podle použitých portů nebo IP) nebo i přímo na počítači (pak to lze vztáhnout na konkrétní aplikace) - např. u Woken viz https://learn.microsoft.com/en-us/powershell/module/netqos/new-netqospolicy?view=windowsserver2022-ps

 

@r2d2S downloadem v principu vždy bude problém, protože nad tím, co přichází z internetu do routeru, nemáš jako klient téměř žádnou kontrolu. To nejlepší, co se dá dělat, je začít zahazovat konkétních flows, co překračují nějakou rychlost - u TCP to relativně spolehlivě zpomalí přenos, ale UDP se může dít všechno možné a co bude záviset na infrastruktuře VF a co/kdy ti VF pošle. Se shapováním downloadu jsem si tedy skoro nehrál. Jinak ale ano, jitter je problém i u mě, kabel se prostě s dobře udělanou optikou nedá srovnávat. Pingování defaultní brány (tj. nic blíž asi neexistuje): rtt min/avg/max/mdev = 5.522/7.413/14.094/1.529 ms

Jinak pro OpenWrt jsou přímo připravené packages jako SQM a qos-scripts ( https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm a https://openwrt.org/docs/guide-user/network/traffic-shaping/traffic_shaping )

Upraveno 26. listopadu uživatelem DiDiDi