GNOME Bugzilla – Bug 418181
Network History: Y axis doesn't indicate full scale value
Last modified: 2011-11-11 10:03:55 UTC
The bug has been opened on https://launchpad.net/bugs/92119 "Binary package hint: gnome-system-monitor The Y axis has 0-100% scale/marks on the left/Y axis. However, since the full scale value isn't indicated anywhere, having % marks doesn't actually provide any useful information. To remedy this and make the scale useful, either remove the % marks and replace them with actual speeds in Kilobytes per seconds, or keep the percentage value, but indicate the full scale value somewhere (and update it dynamically of course, since it changes frequently) just like it is done for the swap and RAM graphs for example. ProblemType: Bug Architecture: i386 Date: Wed Mar 14 03:48:44 2007 DistroRelease: Ubuntu 7.04 ExecutablePath: /usr/bin/gnome-system-monitor Package: gnome-system-monitor 2.18.0-0ubuntu1 ..."
*** Bug 441471 has been marked as a duplicate of this bug. ***
Created attachment 100871 [details] [review] test implementation Here is a proof-of-concept implementation. It's pretty dodgy, i.e. a bit hacky with some badly named variables and functions, so if you like the general idea then I'll clean it up. :)
Created attachment 100872 [details] screenshot screenshot of above implementation
A much simpler patch is possible. The main issue is which unit to use : power of 2 or power of 10 ? The other issue is about having the right indent value (can't be fixed anymore)
Looks nice. Only problem, but a big one... the bandwidth ISP's provide is generally very asymetrical, with a lot more downstream B/W than upstream. My ISP for example is horrible, they offer 100Mbps downstream, but only 1Mbps upstream ! So, in practive this means that the graph for the "Send" plot, will alwyas look like a flat line at the bottom of the scale, making it useless :-/ So, we need a separate/extra Y-axis for the "Send" graph, so it can have a different, much lower full scale value. Either that, or keep the relative/% scale, but display independent FS values for the two graphs.
I agree with Vincent about the upstream and downstream bandwidth allocations. I would prefer to see two separate graphs for each side-by-side with their own Y-axis scales.
(In reply to comment #4) > A much simpler patch is possible. Sure, what do you suggest? Getting a nice vertical scale is nontrivial, and in that implementation there are still some big issues, e.g. if the max is 2kB/s then the all intermediate ticks will be rounded down to either 1 or 0 kB/s, which looks silly. > The main issue is which unit to use : power > of 2 or power of 10 ? The other issue is about having the right indent value > (can't be fixed anymore) > AFAIK the most common units for network speeds are b/s (bits per second) with powers of 10. The current patch uses B/s but that can be easily fixed. The right indent value can be fixed, as long as the numbers are always a maximum of 3 digits. That's not a problem in the current implementation assuming that the network speed is less than 900 GB/s.
Created attachment 101787 [details] [review] Improved patch This implementation is slightly more complex but also much less hacky and produces better axis labels. The reason behind the 10, 25, 50, 75 round-up is that when each of these values is multiplied by 8 (to get the bit rate) the resulting value will be reasonably nicely divisible by 2, 4, and 5, which are the possible numbers of ticks. I've tried a few other rounding algorithms but this seems to work the best (in my opinion). If you have any better ideas then let me know :) Allowing floating point number in the axis labels also fixes the previously described integer rounding problem.
Same comment as previously: what unit should be used ... I'm mostly offline this week, i'll attach my patch for it on saturday so you can compare.
(In reply to comment #9) > Same comment as previously: what unit should be used ... Answered in comment 7: bits per second with powers of 10 is most common for network speeds. I didn't change the "sent" and "recieved" labels yet in case Karl wants to modify those in bug 328101. > I'm mostly offline this week, i'll attach my patch for it on saturday so you > can compare. > Ok, cool. I'll be looking forward to it :)
I've commited something, to try to get a smart rounding.
Created attachment 102180 [details] [review] patch to make download scale I just saw a funny bug in the latest build by chance. The net graph shot off the top of the scale for some values. I think this is due to a bit of code in function net_scale() in load-graph.cpp. The _download_ value in g->data[] is _only_ updated if the _upload_ data is more than 0.0f. I think this patch will solve the problem. As you can imagine this is hard to reproduce. Please review this patch and see if you agree.
Sorry I got up and down confused but you know what I mean I hope. 0/1, Up/Down it's all the same ;)
Created attachment 102182 [details] error OK, My last patch didn't solve this problem. But, I think is still valid? It's easier too reproduce than I thought... just wait. This time I have a screenshot though.
Created attachment 102186 [details] [review] a patch that might have some hope of making a difference ;) OK, that was silly! I think this is a much better plan. I think that the value just scales over 1.0. I'm sorry C++ isn't my 1st language
The net_scale code is old and tested. Have you ever seen some data > 1.0f ?
Created attachment 102197 [details] [review] another try This one should be correct, but the numbers are not nice. Working with power of 2 units is hard to me, but i think, i'm close to the solution.
I've commited an improved version.
(In reply to comment #16) > The net_scale code is old and tested. Have you ever seen some data > 1.0f ? > I put an assertion of data[i][0]<=1.0f in the scale loop and it would abort within 2mins with the old code. The new code works great. No problems with the assertion now :)
Yup, there was a bug where the new_max was actually lowered instead of being increased.
The committed implementation is nice - much better than my version. That being said, there is still the minor issue of the ugly "0 bytes/s" having different units from the other values (which will be either KiB/s or MiB/s). Patch coming soon.
Created attachment 104247 [details] [review] force the "0" value to be in the same units as other values
I've commited a much simpler version :) http://svn.gnome.org/viewvc/gnome-system-monitor?view=revision
Cool. I prefer my way, but there's no point arguing :) Can this bug be closed now?