Vlákno názorů k článku Český telekomunikační úřad pro své PR manipuluje daty od Jirka - Porovnávat průměr z rána s průměrem během dne...
-
Porovnávat průměr z rána s průměrem během dne absolutně nic neříká. NetMetr mi běžně změří ve 3 ráno 50 Mbit, ale přes den kolem 30 Mbit, ale taky neví nic o aktuálním vytížení dané linky. Takže je vcelku logické, že přes den se budou rychlosti pohybovat někde kolem 2/3 maxima.
Aby mohli tvrdit co tvrdí, tak by opravdu museli mít data za několik týdnů a měsíců a pak mohou říci, mělo jejich nařízení nějaký smysl. Tohle je tvrzení o blátě a o louži, která je víc mokrá, protože zrovna pršelo.
Jestli to myslí doopravdy, ať si zřídí testovací přípojky u vybraných ISP a dělají z toho nějaké závěry. Tam budou znát přesné parametry linky i to, že linka není jinak vytížena a mohou testovat a sbírat relevantní data. -
A ještě doplním, že mnohem větší problém vidím v tom, že v podstatě všechny měřáky měří na více spojeních (4-8). To je hezké, že se linka ždíme na maximum, ale pak člověk stahuje jedním spojením jeden soubor a kouká, když linka jede třeba na 20% maxima. Některé druhy řízení provozu přesně tohle dělají. Takže by stálo za to mít možnost zvolit i test rychlosti na jednom vlákně.
Pro porovnání:
Stahování (download)
1 vlákno: 44,1 Mbit/s (5,51 MB/s | 44104 kbit/s)
více vláken: 96,4 Mbit/s (12,0 MB/s | 96363 kbit/s) -
stahování na jednom vlákně je přece úplně jiná disciplína, tam do toho mluví výrazně latence (v případě TCP zejména). Zajistit při vyšších rychlostech saturaci na jednom vlákně je pěkně obtížná disciplína plná magie, ty protokoly nejsou na tohle navržený, i běžný web je složen ze spousty samostatných souborů a nikoliv jednoho velkého.
-
V principu ano, ale v komentáři, na který reagujete, je řeč o rychlostech do 100 Mb/s. I kdybyste měl RTT 100 ms, tak vám na takovou rychlost pohodlně stačí 1.5MB buffer i s rezervou. (Tedy pokud nemáte navíc netriviální ztrátovost, ale pokud máte, je to problém sám o sobě.) Pokud bychom se bavili o gigabitu, tak neřeknu, ale jestli má někdo na trase s dostatečnou propustností problém saturovat 100 Mb/s, tak je někde něco hodně shnilého. Ani šifrování by nemělo hrát roli, takovouhle rychlost by měl zvládnout jakýkoli dnešní procesor, ale na měření propustnosti se snad HTTPS nepoužívá.
Zajistit při vyšších rychlostech saturaci na jednom vlákně je pěkně obtížná disciplína plná magie, ty protokoly nejsou na tohle navržený
To je sice pravda, ale "vyšších" v tomto kontextu znamená rychlosti v řádu desítek Gb/s, ne 100 Mb/s, to nebyl problém ani před dvaceti lety. A ani v těch vyšších rychlostech to není problém TCP.
i běžný web je složen ze spousty samostatných souborů a nikoliv jednoho velkého
To sice je, ale prohlížeč má typicky limit na počet současně používaných spojení s jedním serverem. Ono by to ani nebylo praktické rozkládat na příliš mnoho spojení, protože většina těch souborů je malých, takže kvůli režii na navázání spojení (TCP handshake, TLS handshake, HTTP - pokud se nepoužívá QUIC) by to bylo neefektivní. Navíc uživatele propustnost obvykle nejvíc zajímá ve chvíli, kdy stahuje nějaký velký soubor, ne při běžném prohlížení webu.
-
ouhf.
Při parametrech spojení:
RTT 100ms
MTU 1500
TCP CWND 65535
packet lost: 0Dosáhnu v jednom TCP spojení přenosové rychlosti 5000 Mbit/s. Na to, abych saturoval 100Mbit/s síť bych potřeboval dostat RTT na 5ms nebo naopak zvednout TCP CWND asi 20x.
RTT 100ms je ale dost vysoké číslo, zpravidla můžeme asi počítat s 20ms, v tom případě jedno TCP spojení dokáže přenést nějakých 25000 Mbit/s.
Jak to počítač ty? Třeba se to za ty roky změnilo a dnes se to již počítá jinak.
-
CWND je congestion window, to je hodnota, kterou si odesílatel počítá průběžně sám podle toho, jak reaguje příjemce a jaký používá congestion control algoritmus. Možná jste spíš myslel (advertised) receive window, ale ani tam snad není potřeba automaticky předpokládat, že jedna ze stran neumí window scaling (rozšíření, které za pár měsíců oslaví 30 let), aby bylo potřeba ho zastropovat na 65535.
Realita je taková, že ze serverů, u kterých není limitujícím faktorem něco jiného, nemám problém stahovat velké soubory rychlostí 60-70 MB/s (ano to B je velké) a i ten webový speedtest doporučovaný ČTÚ mi ukazoval IIRC nějakých 650 Mb/s down a něco kolem 900 Mb/s up. Tedy hodnoty podstatně vyšší, než co by podle vás mělo být teoretické maximum.
-
Vidím, že nejsme v rozporu.
Ano a congestion window je přece důležité při stahování, protože určuje kdy odesílatel zastaví posílání dat a počká na ACK, to já jako klient neovlivním a ani nezjistím, advertised je pouze informace. Window scaling dnes umí asi všichni, scale factor se ale dohaduje při inicializaci TCP, tady může být první brzda. Získat velké okno někdy trvá poměrně dlouho a právě nestabilita internetových přípojek tomu moc nenahrává.
Zrovna ale tyhle speed testy používají vícevláknové měření, ne? Nettest.cz vidím, že uvádí 3 spojení na DL.
Všechny ty uložišťové servery používají převážně BBR (uloz.to, youtube, fastshare, twitch, cloudflare atd.), zatímco drtivá většina klientů a ostatních webových serverů ponechává CUBIC (protože je výchozí na většině linux distribucí, ve Windowsu), ten se vyloženě řídí packet loss parametry a dost agresivně snižuje window size a jeho chování je ta magie, o které jsem se zmiňoval. Nevíte náhodou někdo jaké nastavení mají tyhle testovací služby?
Zrovna ten rozdíl mezi DL a UP, který uvádíš u tebe (předpokládám, že máš symetrickou 1Gb/s linku) může být dán jinak zvoleným congestion control algoritmem a nikoliv parametry (či vytížením linky).
-
Ano a congestion window je přece důležité při stahování, protože určuje kdy odesílatel zastaví posílání dat a počká na ACK, to já jako klient neovlivním a ani nezjistím
Je to hodnota, která se dynamicky počítá v průběhu spojení, takže je nesmysl napsat "TCP CWND 65535" a vycházet z toho jako z pevně dané hodnoty.
scale factor se ale dohaduje při inicializaci TCP, tady může být první brzda
Nic se nedohaduje, každá strana té druhé hodnotu prostě oznámí ve svém prvním paketu (SYN resp. SYNACK) a druhá ji vezme na vědomí a podle ní pak interpretuje hodnotu window. Jediné dohadování spočívá v tom, že když některá ze stran scaling neoznámí, má se za to, že rozšíření nepodporuje je potřeba brát hodnotu z window bez shiftu - ale to už se naštěstí moc nestává. Přinejmenším linuxový stack scaling factor volí tak, aby stačil pro maximální přípustnou velikost send bufferu.
Všechny ty uložišťové servery používají převážně BBR (uloz.to, youtube, fastshare, twitch, cloudflare atd.), zatímco drtivá většina klientů a ostatních webových serverů ponechává CUBIC
Pokud přenos dat probíhá převážně jedním směrem (což je typické v situaci, o které je řeč), je congestion control algoritmus zajímavý jen na straně odesílatele, takže je jedno, jaký používá příjemce.
Zrovna ten rozdíl mezi DL a UP, který uvádíš u tebe ... může být dán jinak zvoleným congestion control algoritmem a nikoliv parametry (či vytížením linky).
To bych neřekl. Při experimentech v lokální síti s latencí simulovanou pomocí netem pořád není problém nasytit ani 10Gb/s ethernet, natož 1Gb/s. Teprve při opravdu vysoké ztrátovosti (jednotky procent) kombinované s vysokou latencí (RTT v desítkách ms) začnou být vidět problémy.
Ta asymetrie nebyla ale podstatou příspěvku, podstata byla, že TCP, a to ani přes reálný Internet, nemá problém ani s více než o řád vyššími rychlostmi než těmi, o kterých jste tvrdil, že by měly dělat problémy. Po pravdě jsem zatím neměl potřebu zkoumat, proč to takhle vychází, a ta rychlost je koneckonců nad 60 procenty požadovanými ČTÚ, takže je to vlastně v pořádku. :-)
-
Je to hodnota, která se dynamicky počítá v průběhu spojení, takže je nesmysl napsat "TCP CWND 65535" a vycházet z toho jako z pevně dané hodnoty.
Je to jeden z parametrů existujícího spojení, spoluurčuje mi jeho přenosovou rychlost, nikde jsem nepsal, že to máš měnit nebo nastavovat. Je škoda, že vlastně tyhle měřící služby neposkytují více informace o daném spojení.Pokud přenos dat probíhá převážně jedním směrem (což je typické v situaci, o které je řeč), je congestion control algoritmus zajímavý jen na straně odesílatele, takže je jedno, jaký používá příjemce.
A píšu snad něco jiného? Samozřejmě je to na straně odesílatele dat, tj. buď stahuji, je to na serveru, nebo posílám, je to u mě. Při měření rychlosti se měří oba dva směry, takže i nastavení klienta má vliv na naměřené hodnoty.
No lokální síť, to je trochu jiné prostředí než wan, ne? Z terénu to vidím jinak, chybovost už v hodnotě 10^-4 způsobuje pokles window_size o dva řády v případě Cubicu, to je pořád ztráta paketů pod 1 %. U lokálních sítí s tímhle samozřejmě nejsou problémy, o tom ani tyhle měření nejsou.
ČLÁNKY DO MAILU