GNOME Bugzilla – Bug 88654
Network load auto-sizing works badly
Last modified: 2020-11-06 19:56:21 UTC
When the "network load" view is enabled, there is obviously no way of automatically determining what 100% bandwidth is, so the range is automatically adjusted every time network usage exceeds what was previously thought to be the maximum (at least, such is my understanding of how it works). The problem with this is that occasional spikes can destroy the relations of everything. While downloading binaries from a newsgroup, I can get a consistent transfer rate of about 250 K/sec from my ISP's server... however, a spike may reach well over 500 K/sec, at which point 250K/sec (which is pretty much my maximum bandwidth) only shows up at about 50% usage until I quit and restart Gnome. Perhaps the program should ignore spikes that last less than a certain amount of time, or allow you to set a value that represents 100% usage? (Even a menu option labelled "Reset to defaults" would be great)
*** Bug 69943 has been marked as a duplicate of this bug. ***
Anyone a suggestion how we can solve this because it makes the network traffic monitor within the multiload applet basicly useless.
*** Bug 147247 has been marked as a duplicate of this bug. ***
> Anyone a suggestion how we can solve this Just add a preference where the user can enter what their upstream bandwidth is. Assume that any spikes above that are LAN and not WAN and clip them. Also, the tooltip just says "Network: 1% in use". It might be more useful for it to say (in addition to percentage) what the current kbps in use is. At least then I'd have some idea what's going on even when the percentage is wrong.
What is the status of this bug?
*** Bug 162053 has been marked as a duplicate of this bug. ***
It's still relevant. Bumping version.
Fixed in CVS HEAD.
I suppose this already hit the FTP archives (in form of a release), right?
Comment from the Ubuntu bug (http://bugzilla.ubuntu.com/show_bug.cgi?id=9129): The GNOME bug report has a comment from exactly a year ago today saying that this has been fixed "in CVS HEAD". A year later, the fix still hasn't made its way into dapper. There's still no way I can see to set the maximum, so the applet auto-scales and is therefore basically useless. I'm on a 6Mbit link, and am currently transferring a steady 10Kb/s - that's around 1% of capacity, but the applet is showing "100% in use". If I could tell the applet that 100% means 6Mbit/s then it would know that I'm using effecting no bandwidth. Has this bug been overlooked? It is marked as "RESOLVED FIXED". I'm running gnome-applets version 2.13.1-0ubuntu3.
What do you want exactly : auto-scaling ? no scaling at all ? user set scale ? I take mutliload-applet as it : it give me info about network activity. If i want numeric output, i use netload. May be we could first of fall change multiload tooltip to display network speed instead of %
"it give me info about network activity" - what info does it give you? It gives you a percentage "50% in use". What does that mean, when it doesn't tell you what scale it's using? The graph shows how much of the network is in use compared to a few seconds ago, but that's all. The only info it gives you is "the network is a bit busier than it used to be". With no scale information it's meaningless.
"use netspeed" :) so what's best ? display rates in the tooltip ? have a fixed scale to 100Mb or 1000Mb ? If it displayed a scale information, like '5,33Mb/s', would you be able to guess that this 10px spike means that network activity once reached 2,5Mb/s ?
btw, now that system-monitor displays scales, i'll try to push a patch before UI freeze to display rates instead of %.
Did you have luck with pushing the patch in?
no sorry :/
Did you push in the patch now?
Created attachment 78829 [details] [review] show sum rate
Hi, the patch from Benoît looks really nice, I'd love to see in the tooltip the rate instead of a meaningless percentage :-) Any hope to get it included? Also, to make the graph more useful, instead of using linear scale, you could use a logarithmic scale. Spikes would be less noticeable, and when the usage is low for a few seconds, the differences during this period could be seen more easily. It would still need auto-scaling, but it could be much less often, and the minimum for the high value could be bigger.
Created attachment 122027 [details] [review] Show rate in the network load tooltip instead of percentage Here is an update to Benoit's patch for the latest svn version. I've also enhanced it by separating the receive and sent rates, as well as using the standard g_format_size_for_display() instead of free coding it. The information and strings should now be completely consistent with gnome-system-monitor. Please apply :-)
Patch applied with one minor change: The bandwidth reported before the buffer had been filled was the total number of bytes ever transfered through that interface since the older variable will be 0 in that case. I adjusted the condition in the if statement in netspeed_get to allow for this. I'm leaving the bug open since the main display still has an issue, but this problem is unlikely to be fixable with the current visualisation since available bandwidth is difficult to determine (and variable if you swap between networks with your laptop). A visualisation that was packet based would work better, since that is closer to what actually happens, but I don't have any good ideas about how to do that well.
Thanks for committing, and catching this little bug! Could you explain more what you mean by "packet-based visualisation"? Or maybe you know a program which does this already?
What I mean by packet-based visualisation is something similar to the flashing LED on a NIC or router. The LED gives a brief flash when a packet goes by meaning it gets brighter and less flickery when the number of packets per second increases. I don't think particular example translates very well to the netload applet and it doesn't allow for packet length. The simplest method I can think of is just to draw a vertical line when a packet comes in during the sampling interval, this wouldn't give any quantitative information about the bandwidth, but it would easily distinguish between no network activity, infrequent activity and high activity. Unfortunately on networks with a lot of broadcast packets in the background (like my workplace) this would render the applet useless since it would become a solid colour. If you want a properly quantitative approach, then a packet-based approach won't help the fundamental problem of scaling to an unknown peak value, but it may be suitable for giving a crude estimate that doesn't suffer from the spikes that comment 1 complained about. The scaling problem may also be helped by using a logarithmic scale, but that presents a lot of problems when explaining it to people who aren't used to reading such a scale.
Can I suggest that the graph's present behaviour could be made to work, with a few adjustments? 1) Ignore short spikes, to stop graph scaling up as often. 2) Lengthen 'memory' of top speed reached, to stop it scaling down as often. 3) When it does rescale, replot the whole graph, rather than just applying the new scale to whatever is plotted from then on, because it looks very incongruous when you start downloading something with a spike, and the graph ends up looking like traffic has dropped. I hope you can come up something anyway. Thanks.
*** Bug 378152 has been marked as a duplicate of this bug. ***
*** Bug 531161 has been marked as a duplicate of this bug. ***
Why did nothing ever happen with the rescaling issue? I think Mike Gentry's suggestions make very much sense, and I would like to add the following suggestion: add an option in preferences to select between the following: 1) Continuous autoscaling, as it works today 2) Never downscale, i.e., set the maximum on the scale to the highest peak seen so far. This peak could be subject to a short time average to avoid unrealistically high values. 3) User-defined maxima, i.e., no rescaling. I'm using version 2.30.0-0ubuntu2.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-applets/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.