Názory k článku Český telekomunikační úřad pro své PR manipuluje daty

Tento úřad již 30 let zajištuje, že máme najdražší:

- mobilní data
- mobilní volání.

Tak se nedivte, že píše co píše. Česká pobočka T-mobile má stejný zisk, jako její matka v Německu. Podívejte se kolik stojí datové balíčky v Polsku. Tento úřad je slouha všech operátorů, kteří zde rýžují. Proč, protože mohou. Je známá informace, že vetšina řídících pracovníků v této instituci pracovalo u firem, které regulují.

To sice nemění, ale pokud se chlubí zlepšením statistik, přestože to "zlepšení" je založeno na porovnání údajů, které kvůli zvýšení hranice porovnatelné nejsou, je to buď hloupost (pokud si to neuvědomují) nebo podvod (pokud ano). Těžko říct, která varianta je horší, ale špatné jsou obě.

Takovou manipulaci ve státní sféře používá kdekdo. Kupříkladu policie se velmi ráda a velmi často chlubí jak jim klesá počet trestných činnů. Akorát zapomenou dotat že neustále mění hranici pro klasifikaci trestného činnu (např. zvedli hranici z 5000 Kč na 10 000 kč a následný rok se s velkou pompou chlubili jak jim meziročně ubylo majetkových trestných činnů).
Na blití.

Nejenom, že má český T-Mobile zisk stejný jako jeho mateřská firma Deutsche Telekom AG v Německu, ale v roce 2020 mu ještě celkem odvedla přes 13 miliard Kč, z toho bylo 5,5 miliardy na dividendách, 4,5 miliardy byla půjčka a za zbytek si koupila u Deutsche Telekomu AG cizí měnu ( asi lepší kurz, než v bance....).

Naposled jsme chtěli v prosinci 2021 jako virtuál s T-Mobile uzavřít regulovanou smlouvu Full MVNo na propojení sítí pro mobilní data, kterou dle licence od ČTU na LTE mobiní sítě musí nabídnout. Přišel nam formulář o 49 stranách v anglickém znění. Tento formulář není smlouva, ale jen žádost, kterou musíme na T-Mobile předat, aby s náma vůbec začali jednat.

Mimochodem funkční datové i hlasové propojení sítí na operátorské úrovni máme v telehausu Ce Colo v Praze realizované s T-Mobile od roku 2015. Ovšem, podle T-Mobile i podle ČTU na základě komerční smlouvy, ne tedy této regulované.

Ani postava Švejka není tak absurdní, jako chování T-Mobile v ČR. Rozdíl je ale v tom, že u Švejka se jeden dobře pobaví a s T-Mobile spíše jen popláče a především zaplatí předražená data ...

25. 1. 2022, 09:26 editováno autorem komentáře

Netmetr používám ve formě integrace do routerů Turris. Výsledky jsou v mém případě v pořádku, jsem někde kolem 90% inzerované rychlosti. Pokud však dělám test přes web, pak jsou výsledky na nic (zřejmě pomalé rozhraní serveru). Nicméně se mi několikráte stalo, že mi na mých 1000 Mb/s jelo připojení třeba 400 Mb/s. Jak potom Netmetr vyhodnotí, zda se jedná o UPC 1000 Mb/s nebo 500 Mb/s, jak vůbec dokáže netmetr zjistit jakou mám mít rychlost, když zná pouze poskytovatele dle IP? Pak se jedná o kvělých 500 Mb/s nebo hrozných 1000 Mb/s? Nejpřesnější mi přijde Speedtest CLI by Ookla.

25. 1. 2022, 07:36 editováno autorem komentáře

Na ČTÚ mám svůj specifický názor. Podával jsem si tam stížnost na providera, protože měl výpadek 48h a chtěl jsem po něm odpovídající slevu. Na stížnost jsem od ČTÚ dostal odpověď, že to nemůžou řešit protože výpadek nebyl pod hranicí 95%. Tak jsem to paní inzenyrce spočítal. Bylo to 94,65%... Paní inzenyrka zřejmě čekala, že neumím počítat a nebo sama se svým titulem zkrátka neumí matematiku základní školy...

Děkuji, opravdová novinařina se už příliš často nevidí... Lupa umí!

Že státní úřad manipuluje daty (tím spíš nechvalně známý ČTÚ...), že volně zacházejí s rozdílem mezi opodstatněnou kritikou a názorem, že... že to ještě někoho překvapuje! :)

V tomto pohledu lze spatřovat pozitivní dopad VO-S/1 na kvalitu služeb přístupu k internetu.

Jistě že ho tam lze spatřovat... když člověk hodně chce.

...že by další aktivita odbornice Továrkové...?

Webovy test silne ovlivnuje vykon CPU - testuje se spis vykon PC pouziteho pro test a nikoliv propustnost samotne linky. Zvlaste na vyssich rychlostech je to pro nejake seriozni mereni nepouzitelne.

Pojďme založit nejakou aktivitu za zrušení ctu.

Když pak budou politici mit něco proti, tak po nich budeme chtít, ať tedy daj na stůl lepší variantu.

Ja myslim, že v této situaci je třeba na problem upozornit takovymto odpovídajícím způsobem.

Už se mi i stalo, že např. Speedtest dokázal poskytnout daleko přesnější výsledky měření linky, než Nettest. Asi se jim ucpala linka, když měřilo víc lidí najednou. Takže vypovídající hodnota byla menší. No má to rezervy a nad 200-300 Mbit/s raději ten Speedtest.

Články bez relevantní oponentury jsou vždycky PR. Je jedno jestli rychlost internetu, účinnost očkování nebo prospěšnost nošení roušek.

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)

"Neochota vysvětlit, jak úřad došel k interpretaci ..."
To mi připomíná situaci, kdy nám napařili pokutu, kde mimo jiné psali "Úřad považuje za prokázané...", naše argumenty nebrali v potaz, nepomohlo nic. Sílu se s nimi soudit jsem tenkrát neměl, bohužel.
Od té doby je odbor kontroly v JM kraji na naší černé listině, komunikace jedině přes právníky, datovou schránkou atd.

Oni se hlavně snaží sami dostat se pod hranici trestného činu... Před pár léty mně nějaký dobrák vykradl auto, nejdřív se snažil vydloubnout zadní okno asi šroubovákem, takže orval plechy kolem okna a nakonec to okno rozbil. Odhadl jsem škodu na 12 tisíc Kč, policajti trvali na tom, že je to pod 5 tisíc (tenkrát to byla ona hranice), nakonec jsem jim řekl, ať mně dají papír pro pojišťovnu a napíšou si tam, co chtějí. Tak mně dali papír s částkou 4 900,- Kč a za týden poslali dopis, že nikoho nedopadli. Oprava nakonec stála 16 300,- Kč...

Policie mění hranice škody, která dělá rozdíly mezi přestupkem a trestným činem? Aha... asi ne, co?

Přesně. Důležité, že ve statistice si to vykážou jako pouhý přestupek...a opět se pochválí za klesající trestnou činnost.
Totéž ti hajzlíci dělají na poli legálního držení zbraní. Vykazují "hrozivá čísla" trestných činů s legálně drženými zbraněmi. Jenom ale zapomenou dodat, že tam mají nože (těch je zdaleka nejvíc), sekery, kladiva, plynovky, flobertky, airsoftky a pod.
Všechno jsou to z pohledu zákona legálně držené zbraně. Ale účel to splnilo..veřejnost je "vyděšena" a volá po "opatřeních omezující legálně držené STŘELNÉ zbraně" (kterých je v trestné činnosti 0.7 PROMILE).
Inu, tak se to dnes dělá...

26. 1. 2022, 13:16 editováno autorem komentáře

To je zkreslení změnou metodiky. K dalšímu zkreslení dochází neohlášením případu, protože to poškozený považuje za ztrátu času. Důsledek: Těžko něco vyvozovat z chybně získaných dat.

P. S.: Ve slově „činy“ stačí jedno „n“.

ČTÚ je třeba, ale funkční, takže nemá smysl aktivita za zrušení, ale přeobsazení.
Jak by toho mělo být dosaženo?

To už se tu řešilo, že měřením ve vybraném intervalu nejde dokládat funkčnost nařízení, které platí pro kterýkoliv interval.

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.

Dobře, maličko jsem to tu nastínil, nicméně zásadní mi přijde odpověď na otázku, jak Netmert, potažno ČTÚ zjišťují jaký mám tatif, resp. rychlost, aby mohl zhodnotit zda je to cajk? Mohl by autor položit se svou novinářskou práxí tuto otázku ČTÚ? Snad nemají přístup k informacím o IP a podrobnostech? Jinak článek velice trefný.

25. 1. 2022, 20:03 editováno autorem komentáře

Osobně mi náhodou jejich vyjádření přijde v pohodě.

"Máte v některých oblastech měření QoS jiné názory a máte na ně právo. Naše zkušenosti z měření jsou odlišné a nepovažujeme za vhodné Vás přemlouvat ke změně názorů."

Samozřejmě chápu, že je nějaká snaha hledat senzaci a nahnat si i vlastní čtenost, na základě trefování se do úřadu to jde snadno, ale nepřijde mi to na místě. Ale samozřejmě je to jen můj názor a každý může mít jiný. :)

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.

ČTÚ mi naměřil rychlost vkládání 2,4 Mbps.

https://nettest.cz/cs/Result?f9a139ed-9608-4755-b79a-53744ef23191

Je důležité také uvést, že hodnota rychlosti vkládání odpovídá transportní vrstvě Vaší služby přístupu k internetu (připojení k internetu), a to při použití protokolu TCP, tedy nejčastěji využívaného protokolu transportní vrstvy z pohledu koncového uživatele.

Protokol TCP = Takový Český Protokol

Ale nechápu, proč používají termit transportní.. přitom je to správně právě přepravní vrstva, na které probíhá vkládání.

25. 1. 2022, 17:03 editováno autorem komentáře

ouhf.

Při parametrech spojení:
RTT 100ms
MTU 1500
TCP CWND 65535
packet lost: 0

Dosá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.

už to vidím, počítáme to stejně, ty jsi mluvil o tom bufferu hned na začátku.

Magie je právě ten window scaling, packet loss u internetových příkojek a nikoliv u kontrolovaných sítích.

Těch způsobů, jak statistikou prosazovat svůj zájem, je více. Někteří manipulátoři např. nerozlišují legální a nelegální zbraně, zneužití od nutné obrany nebo vraždy od sebevražd.

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).

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.

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.

A co jsi dělal v Emirátech? Tam to asi ČTU řešit nebude...

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. :-)