Měření rychlosti / dosahovaná rychlost

Software [CZ]
1

Dobrý den,

doba homeoffice přináší nové nároky na rychlost připojení, tak s tím trochu laboruji a narazil jsem na takovou zvláštnost. Moje internetová konektivita je VDSL od T-Mobile (program 100/10Mbs), z DSLAM vede linka do T-Mobilem dodaného DSL Routeru ZyXEL VMG3312-T20A, v bridge mode. Z jednoho z jeho LAN portů vede kabel do WAN portu Turris 1.0, který dělá vlastní PPPoE. A přímo na tomto Turrisu je speedtest-cli, kterým se snažím měřit rychlost připojení.
A teď přijde to divné. Pokud spustím speedtest standardně, bez parametru –single, dostávám vždy hodnoty okolo 40Mb down, 10Mb up.
40Mb
Pokud přidám parametr –single, který by místo více paralelních spojení měl měřit jen na jednom socketu, dostanu vždy se rázem na výrazně vyšší hodnoty, blížící se nasmlouvané maximální rychlosti:
80Mb
Je mi to divné. Nemělo by to být spíše obráceně (když už ne nastejno)? Případně, nechybí mi někde v konfiguraci Turrisu nebo toho VDSL routeru někde něco, co mi zbytečně limituje rychlost na více paralelních socketech? Poradíte někdo?

Druhý dotaz, nesouvisející. Někde jsem zahlédl, že i v uvedené konfiguraci lze nějak dosáhnout toho, že ten VDSL router, ač v bridge módu, poskytuje na svých zbývajících LAN portech a WiFi konektivitu do internetu, zprostředkovávanou vlastně tím Turrisem. Nenasměrujete mě někdo na nějaký návod?

Děkuji

2

K druhému dotazu: Zkus laborovat s návodem na starém fóru. https://www.turris.cz/forum/topic_show.pl?pid=3129. V bývalém bydlišti jsem to měl funkční na T1.1 kvůli přístupu k VDSL modemu. Porty jsem nepotřeboval

3

Osobně bych radši měřil z PC připojeného kabelem k Turrisu, zvlášť pokud jde o měření spouštěním “binárky odněkud”.

4

V podstatě máte pravdu. Na druhou stranu, pro měření přímo z Turrisu mám své důvody a Ookla (autor té binárky) není tak úplně neznámý zdroj.
Nějaký nápad k vysvětlení popsaného rozdílu byste neměl?

5

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í”.

6

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

7

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.

8

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

9

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

10

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
11

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

12

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

13

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

14

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

15

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

16

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

17

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

18

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:

19

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!

20

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