Názory k článku
Jak změřit skutečnou rychlost připojení?

Zde je vhodné upozornit, že pokud není uživatel připojen opravdu rychlostí v řádu mnoha Mbit/s, měly by se u dobrého připojení (myšleno poskytovatele) hodnoty pro jednotlivé zdroje lišit pouze minimálně a zároveň se prakticky rovnat rychlosti linky.

Tady bych si dovolil oponovat. Autor ma zrejme na mysli rychlost stahovani souvisleho toku dat - treba pomoci HTTP ci FTP (nejaky velky soubor) - pak ma zrejme relativni pravdu. V pripade, ze se nejedna o tuto hrubou rychlost uz je situace podstatne horsi, protoze uzivatele na lince rekneme 512 (nekdy i nize) kbps a vyssi jsou casto nemile prekvapeny, jak a) poskytovatel obsahu ma "kvalitni" pripojeni, b) jak poskytovatel obsahu ma "kvalitni" zazemi. Odezva a interakce je totiz to, co ocekavaji a je na svete pouze malo vseobecne vyuzivanych zdroju (napr. Google), ktere jsou schopny Vam tu linku zaplnit daty, ktere Vam hodlaji poslat. Nemusime chodit daleko, staci se rozhlednout po domacich koncinach a hned vite o cem mluvim...

Cože? Jak mi Google zaplní linku odezvou a interakcí?

Odezva Google je do 1s (vcetne hledani) - a vysledek zaplni i objemnou linku, odezva jinych publikacnich systemu (Webziny apod. jsou pouze podtridou) jsou sekundy, nekdy i desitky sekund a to jak v zatizenem, tak nezatizenem stavu a potrebne objekty serviruji velmi vlacne. Vzhledem k tomu, jaky objem dat je nucen zpracovat on-demand Google a jaky publikacni systemy je na snade, ze nekde je neco spatne, zbytek necham na Vas anonyme.

no jestli to není tím, že google má tisíce clusterovaných serverů (možná už desetitisíce, už je to pár týdnů co o tom psali) na stovkách linek různých poskytovatů (když počítám i lokální verze google). Na rozdíl od toho naše uprděné servříky mají typicky jeden server (a ještě sdílený s něčím jiným), maximálně zálohovaný na jeden další a u poskytovatelů mají často priority nastaveno na nula, tedy přeteče-li domluvený objem, tak se prostě pakety zahazují či probíhá jiná forma shapingu, a hlavně všechny ostatní spoje na stejné lince s vyšší prioritou mají vždy přednost.
Je to samozřejmě o penězích (z google nám roste jedna z nejbohatších firem, zejména jestli se jim podaří ipo) a také o potřebě - český server čteně stotisíckrát méně lidí a odezva tam není tak kritická. Krom toho si dovolím polemizovat s tím, že "výsledek zaplní i objemnou linku" - vzhledem k bezobrázkovému pojetí google (vyjma images.google.com) je výsledná stránka vždy podstatně menší než libovolná homepage libovolného serveru, i když zapnete zobrazení stovky odkazů, protože přenést 100-150 KB obrázků je jako přenést 100-150 tisíc znaků, tedy řádově 50-150 normostran textu, pakliže budete uvažovat i tcp/ip kompresi, která je u textu podstatně efektivnější (až 90%) než u jednou komprimovaných obrázků.

Vesmes s Vami souhlasim, az na jednu drobnost a sice - bezobrazkove pojeti libovolneho WebZinu je zalezitost maximalne par desitek kB v pripade desnemu sablonovani a maleho vyuziti CSS. Presto je vysledek nejen radove horsi.

Ja vim, jake technicke zazemi v tom hraje nekdy roli, presto si nemyslim, ze jen HW za to muze... proste se na system divam jako celek a proto rikam, ze pomoci tohoto merit propustnost Internetu je docela odvazna metodika...:-)

já s tím souhlasím, až na jednu drobnost - byl-li by nějaký standardní český test, tedy nejlépe prográmek, který by bylo možno spustit na libovolném počítači a ten by v sobě obsahoval třeba 2 (či více) testy rozdělené dle předem zjištěného statistického chování (vymyšlená čísla):
test1: normální uživatel - 30% toku začíná a končí u poskytovatele s pomocí protokolu pop3 a smtp, 5% začíná http protokolem na seznam.cz, 5% začíná http protokolem na idnes.cz, 4% začínají na microsoft.com ... 20% zbylé servery na NIXu, 15% servery mimo .cz
test2: hráč - 10% začíná a končí pop3 a smtp protokolem u poskytovatele, 60% toku začíná a končí na serverech xy.com, xyz.cz, ...
... a tedy tyto shodné testy by spouštěli lidé na různých sítích ISP v různou dobu, tak při dostatečně velkém vzorku by bylo velmi kvalitní porovnání operátorů. Tedy myslím si, že i měření dostupnsoti jednotlivých serverů smysl má, pakliže se srovnávají jablka s jabkama a tedy když honza u isp1 spouští stejný test ve stejnou dobu na stejný server jako pepa u isp2 a udělají to několikrát. Samozřejmě srovnávat ping na google u isp1 a na idnes u isp2 je nesmysl. A každý server má svou vypovídající hodnotu, protože pakliže je objem přenesených dat běžného uživatele na google 100x nižší než na seznam a idnes(což tak jistě bude, protože takoví lidé nepoužívají textové varianty ezinu a google buď nevyužívají, nebo jen defaultní nastavení s max. 20 odkazy a bez obrázků), tak má seznam a idnes stokrát větší váhu než google.

teda na lupu jsem čekal o něco kvalitnější článek, zejména takový, který by se snažil odpovědět na otázku v nadpisu a nejen napsal, proč to objektivně nejde. Co takhle odkazy na webmetery, či populární měřiče rychlosti? Co takhle vysvětlit proč rychlost k poskytovateli != rychlost k koncovému serveru a co to vše ovlivňuje? Co takhle vysvětlit rozdíl rychlosti a propustnosti? Co komprimace dat? A co třeba ten problém, že "rychlost" se nemusí měřit jen na schopnost protlačení určitého množství dat, ale také na rychlost minimálně velkého paketu (zpoždění), což je pro mnohé aplikace (VoIP ...) podstatnější než za jak dlouho se stáhne x giga. A opět specifikovat aplikace a rozdíly. A když už jsme u toho, co takový jitter? Tyto dvě hodnoty se navíc mění podle agregace a jsou ještě horším problémem našeho ADSL než je propustnost.
No prostě něco technického. Jestli tohle měl být úvod k seriálu, tak to beru, jinak je to ale blábol o ničem, který by se hodil tak akorán na živě.

Zasilam alespon par odkazu na merice rychlosti,
treba se to nekomu bude hodit.
http://schema.mistral.cz/speed/
http://www.dsl.cz/index.php
http://rychlost.webprovider.cz/
http://sluzby.volny.cz/tool/speed/

http://www.volny.cz/jbns/rychlost/

http://preview.globe.cz/speedometer/speedometer.swf

Takovyto pojem ma vyznam na me pripojce k poskytovateli. Dale se da mluvit uz jen o volne kapacite paternich linek, (ne)naplnenosti front v bufferech, mnozstvi peeringovych bodu meho poskytovatele po svete a pasmu na nich volnem. Za temito body uz jsou jenom lvi.
Pri stahovani dat z konkretniho zdroje jeste neni radno zapominat na limity serveru (taky muze byt brzdou) a limity Vaseho klienta ohledne zachazeni s TCP (zejmena u nekterych OS).

Zajimave cteni o mereni dostupneho pasma stvorili panove od Stanfordskeho linearniho urychlovace(!).

http://moat.nlanr.net/PAM2003/PAM2003papers/3781.pdf

K měření rychlosti stahování prohlížéčem je vhodný prohlížeč Links, protože zobrazuje současně průměrnou a smomentální rychlost stahování souboru.

ted jsem si meril na www.rychlostpripojeni.cz a celkove mi zadne testy ani na rychlost.cz ci dsl.cz nevychazeji stejne cemu tedy verit ? Jak zjistim aktualni rychlost pripojeni ?