initial experiment with fixed scale view

[thg2k]

Greetings, this patch is not meant for an actual pull, it's just a proof of concept.

I always found extremely confusing the dynamic scale legend which kept changing as service was improving/degrading across the slice view.

I believe with this patch you get a much better feel of the network situation starting with an expected service level.

I can elaborate this patch and make it a command line option, but first I would like to collect some opinions and know whether it could actually make it into the official repository, since for my needs to hackish solution is good enough.

[rewolff]

Well.... I think I agree with you that the original display was confusing.

It depends on what your context is what a "high" delay is. So the dynamic way tried to accomodate that. But as per your suggestion, there is room for improvement.

At home I'm behind a standard consumer ADSL that has a 20ms or so delay. So "long" in that situation would be "more than say 50ms". Here at work I can mtr to my server 70km away and get an average of 2.4ms. So "long" would be > 5ms.... So... can I scale your "fixed scale" depending on my context?

If that is possible, the default is reasonable (either works for lots of people or is simply the old behaviour) then I'll gladly include it into the standard MTR.

[thg2k]

Yes I totally agree with you, the concept of "long" is relative, that's why i thought about making like 3 main fixed scales: "fast", "normal", "slow", and to calibrate it for the most common use cases. So something like:
--scale normal

Anyway you should give it a try to my patch with your ADSL connection as it is now. Before I start coding further, I'd like to discuss exactly how this feature should come along.
Here is a screenshot of my crappy wimax based connection:
https://imgur.com/ysoQo0b

As you can see, you can immediately spot where the problems are, and how long is the latency. In this case, 1 means 5-14ms (so about 10ms), 2 means 15-24 (about 20ms), and so on.

Another idea I had was to use 1-9 for 5-94ms pings (without even showing them in the legend below), and then use a-f or something like that with the same dynamic algorithm that there is now, so it can cover extra long pings which are shown as '>' now.

The rationale behind this is that with the dynamic scale I was seriously confused about the situation of my network, because when I had a spyke of extremely slow pings it would readjust the whole screen and i would lose track of the actual situation when the connection is "decent", so I guess other people would benefit with that.

Of couse then it comes to "tuning" the fixed scale(s) but that can be done at the end, first we need to agree on the exact implementation before i implement it.

Thank you for your time!
Giovanni

[rewolff]

How about if you set up the scale as a reasonable default (what works for you), but then a command line option (which you can set from the ENVironment) to adjust the scale?

--scale 5:15:25:35:45:55:101:200:400

That would mean we don't have to guess what others find a reasonable scale, and someone who is doing interplanetary research does not have to come begging for a new scale variant....... (Apparently :100 is something special)

What do you think?

[thg2k]

I like the idea of specifying it on the command line! I would still provide 3 reasonable keyworded defaults for most common situations, plus the explicit ranges on the command line! So how about:
--scale <slow|average|fast|NN:NN:NN:NN:NN...>

[rewolff]

Yes, that sounds like a good idea. So -scale average would be equivalent to -scale 5:15:25:35:45:55:101:200:400 .

[rewolff]

char *scale_shortcuts[NUM_SHORTCUTS] = {"slow", "average", "fast"};
 int default_scales[3][10] = {{..,.., ... , ..}, {5,15,25,35,45,55,101,200,400} , {...} };