Jasny, to je rozdil iperf2/3, taky jsme to řešili a taky neexistuje funkční alternativa. Navic driv se ty iperfy i zasekavaly, když bezely porad jako server. Klasicky akademický soft.
Naštěstí u nás siti věříme, a zákazníkům ten 20-30g uplink staci, takze iperf3 je na test ok.
Webservery na 100g jsme třeba testovali produkcnim video trafficem ;)
Ale taky si pamatuju, ze iperf hodně ovlivňuje cpu a sitovka, i40e to tuším úplně zabíjelo a museli jsme hromadně měnit NIC jen kvůli tomuhle.
Čím vic jde člověk nad 40G, tím se objevují čím dal vzácnější bugy i v kernelu.
Proto 2x 10/20/40/100G servery testujeme na 20 iperf threadech.
To ale iperf sám o sobě neumí. Sice na rozdíl od netperfu umí víc spojení současně, ale všechno běží v jednom threadu, takže saturovat 40 nebo dokonce 100 Gb/s stejně může být problém. Obvykle se to obchází tím, že se paralelně spustí víc instancí, ale to není moc uspokojivé řešení. Pak jsem ještě narazil na uperf, ale ten vypadá trochu "overengineered" a ne moc praktický pro jednoduché měření (a navíc od loňského dubna nevypadá moc živě). Nakonec mne to dohnalo k tomu, že si zkouším napsat vlastní utilitku.
Na druhou stranu, na loňské Netdev konferenci IIRC Eric Dumazet tvrdil, že se mu s důmyslně implementovaným zerocopy a ve velmi specifickém prostředí podařilo saturovat 100 Gb/s ethernet jedním TCP spojením. Ale to asi nebylo ve webovém prohlížeči. :-)
To je pravda.
Ale stejně tak linka, co má po cestě bond a ECMP se bude chovat jinak.
Proto 2x 10/20/40/100G servery testujeme na 20 iperf threadech.
Driv, když se ještě u nas používaly n x 10 Gbps jako uplinky do switche, to bylo docela znát.
I teď se setkas s tím, ze single thread u Cogentu má rozbitou rychlost na kbps (!), protože to zrovna vzalo nesmyslnou trasu, kde to maj rozbity. Bohužel.
> Každý switch nebo router po cestě přidá daleko více, nežli optická trasa přes celou republiku
Tohle tvrzení lze snadno vyvrátit pomocí trace route kamkoli "daleko". Mám tu případ, kde to skočilo 10x, ale celkově je to do 3ms, jiný případ kde také 10 skoků je za 10ms. V tom druhém případě to kvůli rychlosti světla pod nějakých 6ms ani nejde a právě ty dělají tu prodlevu.
Problém všech těch měřáků je, že měří rychlost na více vláknech. NetMetr 3 vlákna a OOKLA klidně 8 vláken. Potom velmi pravděpodobně dostanete velmi různé výsledky dle typu řízení rychlosti u ISP. Osobně bych testoval rychlost jen na jednom spojení, protože to nejvíce vypovídá o rychlosti např. při stahování souboru jedním uživatelem. U speedtestu je to ta volba single. Test na více vláknech vypovídá o celkové kapacitě linky.
Na 8 vláknech ze speedtest.dkm.cz naměřím klidně 250 Mbps, ale na single speedtest.net třeba jen 50 Mbps. A to už si člověk řekne, na co platí 250 ... Tohle by mělo ČTU brát v potaz taky.
Ideální stav je:
Mám 100 Mbit linku
1 spojení - naměřím 100 Mbit
2 spojení - na každém spojení naměřím 50 Mbit, v součtu 100 Mbit
atd.
24. 3. 2021, 11:59 editováno autorem komentáře
Podle odezvy více než cca 10 ms se pozná, že testovací server je už poměrně daleko. I nejvzdálenější místa v ČR by se měla dostat na těch cca 10 ms do NIXu. Zajímavé je sledovat, jak se mění odezva a hlavně download/upload u různých odlehlejších míst na planetě. Třeba namátkou 250/90 Mbit/s do Kazachstánu. :-)