[atlas] LatencyMON Widget Y axis in milliseconds

Hi Marat,

> On 10 May 2016, at 09:20, Marat Khalili <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 < <mailto:mkh at rqc.ru>mkh at rqc.ru <mailto: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/>https://atlas.ripe.net/docs/tools-latencymon/ <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: </ripe/mail/archives/ripe-atlas/attachments/20160510/784f074a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2611 bytes
Desc: not available
URL: </ripe/mail/archives/ripe-atlas/attachments/20160510/784f074a/attachment.p7s>