Měření rychlosti / dosahovaná rychlost

V podstatě nemám. Předpokládám že CPU to při testu nevytíží.

Obecně bych v případě pochybností nespoléhal jen na jednoho “poskytovatele měření”.

Měření z počítače (a ještě přes webový prohlížeč) může být hodně zavádějící.

Mně přijde, že většinou lidi reálně download vytěžují právě z prohlížeče na počítači, ale jistě záleží na případu.

Pak se samozřejmě dostáváme k otázce, co vlastně chceme měřit.

Ano, ale doufal bych že problém v tomto případě bude jinde. Rychlosti do 100 Mbps nejsou až tak závratné… samozřejmě pokud se testuje proti serveru s rozumnou konektivitou směrem ke klientovi (což tady vypadá OK).

Buďte rádi, že Vám to vůbec něco měří.
Já jsem si na své Omnii (TurrisOS 4.0.5 (hbs)) zapnul userlist “Netmetr” a měření mi končí takovou pěknou chybovou hláškou …

Traceback (most recent call last):
File "/usr/bin/netmetr", line 11, in <module>
load_entry_point('netmetr==1.5.3', 'console_scripts', 'netmetr')()
File "/__main__.py", line 622, in main
File "/__main__.py", line 327, in upload_result
File "/__main__.py", line 94, in send_request
File "/request.py", line 223, in urlopen
File "/request.py", line 532, in open
File "/request.py", line 642, in http_response
File "/request.py", line 570, in error
File "/request.py", line 504, in _call_chain
File "/request.py", line 650, in http_error_default
urllib.error.HTTPError: HTTP Error 400: Bad Request

Pak by bylo skutečně nejlepší vyzkoušet nějaké srovnatelné testy, v tomto případě třeba váš NetMetr a vyloučit, že je to záležitost příslušného nástroje.

Jinak níže něco k rychlostem od nestora českého Internetu.

https://www.earchiv.cz/l226/slide.php3?l=22&me=5

Bylo by možné na support, případně mi do PM poslat výstup z příkazu netmetr --debug? Přepošlu to vývojáři netmetru, který se na to podívá.

Alespoň se nemusíte trápit rychlostí připojení.

Jasně … pošlu :slight_smile:
Díky a zdravím …

V tomto případě ačkoliv se to nemusí na první pohled zdát, tak bad request znamená, že neproběhl upload výsledků na serveru z důvodů selhaní testu na ping. O tomhle problému víme a týká se pouze při používání IPv6 protokolu. Částečná oprave se nachází ve verzi Turris OS 3.11.16 (RC), kde je verze netmetru 1.5.4, která umožní uložení výsledku změření na server i když se test na ping nezdařil. Do verze Turris OS 5.0 aktualizace balíčku je na cestě.

OK … doporučuješ tedy přejít na TurrisOS 5.0 … ve 4.0.5 nebude opraveno?

Pokud už skutečně nemá vyjít nová verze TOS 4, pak zřejmě nikoliv.

netmetr 1.5.4 ma asi jeste nejakou chhybu…
Debug (Turris 1.0) konci takto:

    Starting speed test...
    ==== rmbt v3.11-68-gfe363acb6-dirty ====
    connecting...
    connected with 3 flow(s) for dl; 3 flow(s) for ul
    pretest downlink start... (min 1s)
    pretest downlink end.
    rtt_tcp_payload start... (11 times)
    rtt_tcp_payload end.
    downlink test start... (5s)
    downlink test end.
    pretest uplink start... (min 1s)
    pretest uplink end.
    uplink test start... (5s)
    error in poll of do_uplink: timeout
    error in poll of do_uplink: timeout
    error in poll of do_uplink: timeout
    dl_throughput_mbps = 18.564554
    ul_throughput_mbps = 0.000000
    Exiting.
    Speed test result:
    {
      "cnf_file_flows":"\/tmp\/tmpetmwlgyw.xz"
    }
    {
      "res_id_test":"0fc4025d-ad6f-434d-8e90-ffd4bc210e19",
      "res_time_start_s":1586435744,
      "res_time_end_s":1586435800,
      "res_status":"fail_ul",
      "res_status_msg":"error in poll of do_uplink: timeout",
      "res_version_client":"v3.11-68-gfe363acb6-dirty",
      "res_version_server":"RMBTv0.3",
      "res_server_ip":"217.31.202.97",
      "res_server_port":8081,
      "res_encrypt":false,
      "res_chunksize":4096,
      "res_tcp_congestion":"cubic",
      "res_total_bytes_dl":14434724,
      "res_total_bytes_ul":2085840,
      "res_uname_sysname":"Linux",
      "res_uname_nodename":"molekula",
      "res_uname_release":"4.4.199-f90a52a6230ecb072f657fce5aebd444-0",
      "res_uname_version":"#1 SMP Wed Jan 15 02:28:05 CET 2020",
      "res_uname_machine":"ppc",
      "res_rtt_tcp_payload_num":11,
      "res_rtt_tcp_payload_client_ns":15991118,
      "res_rtt_tcp_payload_server_ns":12718016,
      "res_dl_num_flows":3,
      "res_dl_time_ns":5440926052,
      "res_dl_bytes":12626046,
      "res_dl_throughput_kbps":18564.554459046707
    }

    Traceback (most recent call last):
      File "/usr/bin/netmetr", line 11, in <module>
        load_entry_point('netmetr==1.5.4', 'console_scripts', 'netmetr')()
      File "/usr/lib/python3.6/site-packages/netmetr/__main__.py", line 621, in main
        speed_flows = netmetr.import_speed_flows()
      File "/usr/lib/python3.6/site-packages/netmetr/__main__.py", line 254, in import_speed_flows
        for flow in flows_json["res_details"][d_short]:
    KeyError: 'ul'

Omnia (taky netmetr 1.5.4) se chova stejne.
Na MOXu se mi to nepovedlo vyzkouset (netmetr 1.5.3), protoze sit zrovna fungovala. Skoda ze nemeri ztratovost paketu a jitter jako mobilni aplikace a skoda ze se tyto zajimave udaje nezobrazuji na webu, kdyz se chci podivat na sva mereni pres sync code. Pokud sit funguje, tak se netmetr chova slusne i na Omnia a Turris 1.0.
Tak jen takovy maly bug :slight_smile:

Dobrý den,

máte pravdu. Tenhle okrajový případ opravdu nemáme podchycený. Vyrobil jsme k tomu issue, hotová je i jednoduchá oprava, která teď čeká na schválení. Můžeté nám k tomu dát například palec do gitlabu - to máme rádi. :slightly_smiling_face: Každopádně děkujeme za report!

Moc dekuji za super rychlou rekaci! Nejake dobre zpravy k jitter a ztratovosti paketu merene z turris-e a ne jen z telefonu (a jejich zobrazeni na webu, telefon nezobrazuje historii).

Měření jitteru a dalších QoS parametrů máme v plánu spíše výhledově. Momentálně řešíme hlavně produkční nasazení Sentinelu, takže času na Netmetr je opravdu jen na rychlé opravy.

Limitovaná rychlost, to už tady bylo, už jsem to tu zmínil, ale nikdo nereagoval… Jsem se už bál, že jsem v našich luzích jedinný Turrista s tímto železem. Nám se to nepodařilo rozchodit, jedeme v režimu router… Budu rád za každou informaci jak vyhrát tento Zyxelí boj. Díky.

Dobrý den.
Mám stejný router a také od T-Mobile. Ale zklamu vás, postupoval jsem přesně jak je v tom návodu. Resp. ve webové administraci jsem jen přednastavený profil VDSL přepnul do režimu bridge. Nastavení teď vypadá takhle
VDSL .
Mám Turris 1.0, tam jsem postupoval podle standardního návodu, chytlo se to na první pokus. Jak jsem psal a dokumentoval i obrázky výše, nenazval bych to limitovanou rychlostí. V tom “single” módu to standardně dosahuje v podstatě smluvní “až” rychlosti. Při stahování větších souborů přes FTP se rychlost stahování také blíží spíše této. Při downloadu z různých webových úložišť se tu už začne lišit, zřejmě právě podle toho, jestli daný server používá jeden nebo více socketů. U dcery, na 1G ethernetem připojeném Playstation v podstatě všechny hry, pokud nějak měří rychlost, ukáží těch 40Mbit. A tak dále.
Usuzuji z toho, že Zyxel je v tom nevinně - jestli je bridge, tak je pro něj paket jako paket, nepozná který patří k jakému spojení. A posílá ty pakety opravdu 100Mbit/s. Bude to spíše něco v Turrisu, těžko říct kde. Prostě se pro “nějaké” typy spojení dostane na limit, buď HW (nemyslím), nebo nějakého nastaveného omezení. Proto jsem doufal, že někdo ze zkušenějších poradí něco ve smyslu “v /etc/config/něco změň hodnotu parametru XXX na hodnotu YYY”.
Jak už to bývá, diskuze tu ale rychle zahnula někam úplně jinam …

Mimochodem, nevěděl by někdo jak tomuhle Zyxel routeru vysvětlit, že když je teď toliko bridge, je pro něj default gateway právě ten Turris? To jediné mi chybí k tomu abych na Zyxelu rozchodil LAN porty a Wifi jako funkční porty pro připojení dalších zařízení.
Případně, jaké sakra tam může mít root heslo pro připojení přes SSH. Heslo admina z webové konfigurace to není.

A nemohly by ty zablokované sockety souviset třeba s nastavením pro IPTV? Přednastavené xDSL profily se musí v jiných routrech mazat (viz nefunkční LAN porty, resp. návod na Commtrend na přepnutí do BRIDGE, apod). Nicméně nevím, kde to v tom Routeru přesně hledat. V každém případě jste přišel na něco víc než já. Možná se ptáte lépe a v užším pásmu ootázek než já.

To heslo by mělo být zjistitelné na podpoře ZyXELu. Ta funguje docela ochotně, ale když jsem s nimi mluvil a vznesl pro ně nestandardní požadavek, nebyli schopni mi ihned pomoci a předávali požadavek k výrobci na Taiwan. :slight_smile: