Ticket #385 (new)

Opened 9 years ago

Last modified 5 years ago

Vpeljati ljudem razumljivejše metrike

Reported by: stefanb Owned by: kostko
Priority: major Milestone: Next milestone
Component: nodewatcher/modules Version:
Keywords: Cc: gw0
Related nodes: Realization state:
Blocking: Effort: normal
Blocked by: Security sensitive: no

Description

ETX pri topologiji ljudem ne pove prav dosti. Uporabnike zanima razpoložljiva (oz vsaj teoretična) pasovna širina (oz. ping za igričarje). Točke bi to lahko občasno merile tako na VPN kot na brezžičnih povezavah. (#178, Podrobnosti/MerjenjePovezave?)

Stabilnost točk (trenutno v % uptime-a od njene prve postavitve oz resetiranja števcev) bi bilo smiselno definirati kot % uptime-a v nekem krajšem obdobju (oz nekaj logaritmičnega, kjer ima zadnje odobje večjo težo). (#183, #190)

Kvaliteta postavitve točke oz njene antene s številom uporabnikov/peerov/drugih vidnih omrežij(site survey) v nekem zadnjem obdobju (trenutni in sešteti podatki ostanejo) (#211, #271)

Change History

comment:1 Changed 9 years ago by kostko

  • Milestone set to 3.0b

comment:2 Changed 9 years ago by mitar

  • Owner set to kostko
  • Component changed from ostalo to baza točk

comment:3 Changed 9 years ago by mitar

Hm, ne vem, če mi je všeč obremenjevanje omrežja samo zato, da se izmerijo hitrosti. Vsaj avtomatiziral ne bi tega. Zato smo tudi naredili navodila, da se ve, kako lahko skrbniki te stvari testirajo. Ampak da bi pa to prikazovali kar tako ...

Se mi zdi mogoče smiselno raje narediti pasivno analizo pretoka podatkov. Nekaj v smislu #195. Zdi se mi, da če povsod beležimo količino prenesenih podatkov, potem lahko podobno kot pri #195 nastavimo sistem enačb in izračunamo za vsako točko koliko je kateri drugi točki poslala. Tako bi lahko raje risali graf realnega prometa. Torej realnega pretakanja podatkov. In to bi lahko delali tudi skozi čas.

Glede teh podatkov, ki bi upoštevali le zadnje časovno obdobje oziroma mu dajali večjo, se strinjam. Mislim, da se mogoče že nahaja nekje v ticketih, v kakšnem komentarju. Se mi zdi, da je bilo nekaj povezano z grafi in tem, kako njih prikazujemo po obdobjih in bi torej lahko glede na ta obdobja dodali še druge sorodne vrednosti. Recimo v primeru števila odjemalcev bi se lahko preprosto na graf zapisala skupna vsota vseh v obdobju grafa. Ampak za stabilnost takšnega grafa nimamo, tako da se mi zdi smiselno obtežiti.

comment:4 Changed 9 years ago by mitar

#471 je bil označen kot duplikat tega ticketa.

comment:5 Changed 9 years ago by stefanb

Zanimiva metrika bi bila tudi skupna in povprečna dolžina wifi linkov.

comment:6 Changed 9 years ago by mitar

Misliš linkov vsake točke?

Lahko bi obtežili to s kvaliteto linkov.

Čeprav potem bi lahko ljudje raje postavljali usmerjene povezave, mi pa si želimo pokrivati prostor.

Meni se zdi, da bi glavna dva morala biti stabilnost in število uporabnikov.

comment:7 Changed 9 years ago by stefanb

Ne dolžine povezav posamezne točke, ampak samo skupna dolžina vseh povezav, da ne bi posameznih skrbnikov slučajno motivirali k pretiranem lovljenju dolžin. Poleg predvidene stalne rasti bi bilo zanimivo opazovati nihanje (dolžin in kvalitete povezav) z vremenom in letnimi časi, kar je smiselno le na agregiranih podatkih, ne pa na podatkih posamezne točke.

To je tudi ena taka laikom razumljiva metrika, ki bi jo lahko objavil vsak poljuden medij (npr: "omrežje ima 100km brezžičnih povezav po Ljubljani") in je hkrati tudi neko merilo neodvisnosti omrežja od žičnih vpn povezav.

comment:8 Changed 9 years ago by mitar

  • Cc gw0 added

comment:9 follow-up: ↓ 10 Changed 9 years ago by gw0

Pomoje bi se lahko merjenje odzivnosti (ping) res avtomatiziral, ker res ne povzroca drasticnega povecanja kolicine prometa. Seveda ne prevec, mogoce le 3 meritve preko vseh linkov na pol ure. Seveda bi bilo potrebno vrednosti povprecit, da pridejo smiselne. Iz tega bi se tudi dobilo packet loss podatkek na posameznih povezavah in bi se lahko se natancneje dolocevalo kvalitete povezav.

Za samo merjenje bandwidtha pa bi bilo verjetno pametno imeti neko kombinacijo pasivnega in, ce ni popolnoma nobenega prometa, tudi aktivnega merjenja. Morda le 1 ali 2 krat na dan, da se ne obremenjuje po nepotrebnem. Ali pa le pasivno...

To so pomoje za sirso mnozico najbolj razumljive vrednosti: ping, bandwidth in stabilnost vsake posamezne povezave. Pri stabilnosti tock bi bil uptime, pri stabilnosti povezav pa packet ter connectivity loss v %. To z obtezenjem zadnjega obdobja z logaritemsko skalo pa sploh ni neumna ideja.

Hm, s to "dolzino linkov" je misljena geografska dolzina ali ping tja in nazaj? Ce je misljena geografska, potem je le-ta mocno odvisna od natancnosti popisanih koordinat na nodes.wlan-lj.net in bi se jo lahko dalo izracunati ze zdaj brez meritev iz podatkov v bazi. Ce pa bi se meril round-trip ping paketka, pa se bi lahko medijem le njegovo povprecno vrednost povedalo, ker ostale stvari nekako nimajo smisla.

comment:10 in reply to: ↑ 9 Changed 9 years ago by mitar

Replying to gw0:

Pomoje bi se lahko merjenje odzivnosti (ping) res avtomatiziral

To je že narejeno: #427 in #428.

Za samo merjenje bandwidtha pa bi bilo verjetno pametno imeti neko kombinacijo pasivnega in, ce ni popolnoma nobenega prometa, tudi aktivnega merjenja. Morda le 1 ali 2 krat na dan, da se ne obremenjuje po nepotrebnem. Ali pa le pasivno...

Za to obstaja ticket #517.

Hm, s to "dolzino linkov" je misljena geografska dolzina ali ping tja in nazaj? Ce je misljena geografska, potem je le-ta mocno odvisna od natancnosti popisanih koordinat na nodes.wlan-lj.net in bi se jo lahko dalo izracunati ze zdaj brez meritev iz podatkov v bazi.

Mislim, da je mišljena geografska dolžina glede na omenjene kilometre. Ne razumem o kakšnih meritvah govoriš? Seveda bi se to izračunalo iz obstoječih koordinat direktno, saj imamo za točke njihove geografske koordinate.

comment:11 follow-up: ↓ 12 Changed 9 years ago by Primus

Sem pogledal kaj ticket 517 pravzaprav je, pogledal sem linkano stran a na žalost premalo poznam stvari, da bi razbral kaj točno tisti software počne..
Če bo šlo merjenje po zraku, je ok, merjenje VPN povezav je pa zelo zoprna zadeva, kar se mene tiče.
Sam včasih igram kakšne online igre in ko ping naraste postanejo zadeve neuporabne .... pa čeprav je to za nekaj sekund. Po Murpheyu je to ravno takrat, ko je moteče. Če bi bilo mogoče test nastaviti za posamezno točko na določeno uro bi bilo to bistveno lažje sprejemljivo, čeprav še vedno ne vidim smisla merjenja VPN povezave.

comment:12 in reply to: ↑ 11 Changed 9 years ago by mitar

Replying to Primus:

Sem pogledal kaj ticket 517 pravzaprav je, pogledal sem linkano stran a na žalost premalo poznam stvari, da bi razbral kaj točno tisti software počne..

Jaz sem le omenil, da je diskusija glede merjenje povezav bolj primerna v tistem ticketu. Torej da razbremenimo ta ticket.

Sem pa tudi jaz proti aktivnemu merjenju bandwidtha. Še posebej, ker le-te v brezžičnih povezavah ne pomeni veliko, saj je precej odvisen od trenutka. Ampak ta omenjeni sistem omogoča razne stvari, tako da mogoče gre nastaviti, da meri bandwidth pasivno (nekaj takšnega kot že sedaj počnemo na grafih) tako, da pač gleda koliko je bilo največ realnega prometa poslanega preko in ne nekega umetnega. Čez daljše obdobje se lahko tako izračuna koliko so realne hitrosti, ki jih je možno doseči in kakšne so povprečne. V resnici je sistem bolj smiselno uporabljati za druge bolj tehnične meritve. Torej ping in bandwidth (pasivno) pa merimo že sedaj, sami.

Sam prikaz skupnega bandwidtha omrežja pa se mi zdi nesmiseln, saj sigurno ljudem ne bo jasno, kaj to predstavlja (recimo če bi naredili povprečno prepustnost vseh povezav), saj jih večinoma zanima dostop do Interneta (to si lahko predstavljajo) in hitrost tega je odvisna od konkretne poti do njega in ne celotnega omrežja.

comment:13 Changed 5 years ago by kostko

  • Component changed from nodewatcher/core to nodewatcher/modules
  • Milestone changed from 3.0b to Next milestone
Note: See TracTickets for help on using tickets.