[atlas] LatencyMON Widget Y axis in milliseconds
- Previous message (by thread): [atlas] LatencyMON Widget Y axis in milliseconds
- Next message (by thread): [atlas] ping measurements and high lts
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marat Khalili
mkh at rqc.ru
Tue May 10 13:59:00 CEST 2016
It works! Did not realize it is called this way, thank you! -- With Best Regards, Marat Khalili On 10/05/16 13:31, Massimo Candela wrote: > Hi Marat, > >> On 10 May 2016, at 09:20, Marat Khalili <mkh at rqc.ru >> <mailto:mkh at rqc.ru>> wrote: >> >> Hello Massimo, >> >> Thank you very much for your reply. >>> You can anyway force to open the measurement in ms (the same goes >>> for all the other parameters) if you embed the widget in your html >>> page/monitor/dashboard. >> That's exactly what I'm doing: I've created a web-page on my internal >> web-server that contains the widget. However, I still cannot find >> neither parameter nor API that would allow me to select milliseconds. >> I've read through both documentation page you pointed and poked >> JavaScript object returned by initLatencymon, but still don't see it. > > Option 1: Set the parameter in the embed code (more info at the end of > the documentation page) > dataFilter [string] The data filter name to be used (i.e. natural or > relative). > > So practically you need something like: > { > dataFilter: "natural", > measurements:[MSM_ID1, MSM_ID2] > } > > in your query options map (third parameter of initLatencymon). > In this way the widget will load the measurement with all the default > parameters you set. > > > If you want to change it at execution time: > - open your browser console; > - latencymon.shell().setDataFilter(“natural”), where latencymon is the > object returned by initLatencymon() > > > Be careful: don’t simply reload the page, remove all the parameters in > the permalink. The permalink has priority so if in the permalink you > have another filter, this will overwrite the one specified in the > embed code. > >> >> That said, reference point in milliseconds appeared on charts >> recently, that somewhat makes it less of a problem for me. > > ;) > > But anyway try the solution before, it will fit better your case. > >> >>> The relative representation allows the user to focus on change in >>> the RTT over time and geographic space, instead of a pure comparison >>> among milliseconds of the various probes. >>> Following the user requests and according also to our internal use, >>> this is the most common use case, especially in case of outage analysis. >> My (mis)use case is different: I'm trying to monitor one particular >> link that's important for me, using a single probe and multiple >> nearby destinations. In this case absolute values matter: relative >> charts may look absolutely normal while absolute values are elevated >> from 1..2 to 10+ milliseconds because to link overload which is not good. >> > > Let me know if everything is fine! > > Ciao, > Massimo > >> -- >> >> With Best Regards, >> Marat Khalili >> >> On 09/05/16 18:25, Massimo Candela wrote: >>> Hi Marat, >>> >>>> On 13 Apr 2016, at 10:23, Marat Khalili <mkh at rqc.ru> wrote: >>>> >>>> I'm using LatencyMON >>>> <https://atlas.ripe.net/docs/tools-latencymon/> widget to monitor >>>> my network performance. It's very convenient. Unfortunately, it >>>> always loads with latency shown in %% (of what?), not in >>>> milliseconds, so I have to make one extra click in order to view >>>> actual milliseconds. Is there some hidden switch that would make >>>> milliseconds the default? Shouldn't it be initially default in the >>>> first place? >>> >>> >>> Thanks for your comment, I will try to answer and give my opinion. >>> >>> Here you can find the documentation: >>> https://atlas.ripe.net/docs/tools-latencymon/ >>> According to it: "The relative representation shows, in percentages, >>> how the values behave compared to the baseline, which is the minimum >>> latency collected in the time range for the specific graph. Note >>> that outliers have been removed. >>> For example, if the latencies collected oscillate between 30 and 90 >>> ms, the y-axis will have a range between 0 and 200%, as 30 ms will >>> be considered the baseline and 90 ms represents an increase of 200% >>> over 30 ms.” >>> >>> The relative representation allows the user to focus on change in >>> the RTT over time and geographic space, instead of a pure comparison >>> among milliseconds of the various probes. >>> Following the user requests and according also to our internal use, >>> this is the most common use case, especially in case of outage analysis. >>> For example if you have a probe in Canada and one in Italy and the >>> target used in the measurement is in Germany, you would expect to >>> have some ms more from the one in Canada: this information it’s just >>> going to pollute the graphs. >>> Probably if something happens on the network you would like to know >>> which probes were affected and how. So what is the difference in RTT >>> compared to what is considered “normal” from that source. >>> >>> You can anyway force to open the measurement in ms (the same goes >>> for all the other parameters) if you embed the widget in your html >>> page/monitor/dashboard. >>> >>> Sorry for the delay of the answer, for more information feel free to >>> contact me personally. >>> >>> Ciao, >>> Massimo >>> >>> >>> >>>> >>>> -- >>>> >>>> With Best Regards, >>>> Marat Khalili >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20160510/600b9cd3/attachment.html>
- Previous message (by thread): [atlas] LatencyMON Widget Y axis in milliseconds
- Next message (by thread): [atlas] ping measurements and high lts
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]