GNOME Bugzilla – Bug 535544
network transfer speed is wrong
Last modified: 2011-11-11 10:03:55 UTC
for some reason, gnome-system-monitor tells me I am transferring at 5 Mib/s over wireless G network with my atheros card. This only seems to happen with this card though, as looking at gnome-system-monitor on the sending computer (which has a wired NIC), g-s-m reports 2.5 Mib/s or so. Basically, g-s-m believes I am transferring at 5 Mib/s, however nautilus (gvfs) and netspeed-applet both believe I am transferring at 2.3 to 2.6 Mib/s. Dumbfounded, I did the calculations. My benchmark is transferring a 700 Mib file. It took roughly 5 minutes (~300 seconds). 700 Mib/300 s = 2.3 Mib/s. Therefore gnome-system-monitor is incorrect. This bug is consistently reproducible and has affected g-s-m for as long as I can remember, but until now I thought netspeed was incorrect, or that it was some weird twist of speedbooster technology. Marked as major: data extremely incorrect?
Created attachment 111751 [details] screenshot: g-s-m disagrees with nautilus and netspeed
Looks like you have a pseudo interface for wireless. ifconfig output please.
ath0 Link encap:Ethernet HWaddr 00:14:a4:25:69:31 inet adr:192.168.1.125 Bcast:192.168.1.255 Masque:255.255.255.0 adr inet6: fe80::214:a4ff:fe25:6931/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Packets reçus:6925 erreurs:0 :0 overruns:0 frame:0 TX packets:7047 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 Octets reçus:731443 (714.2 KB) Octets transmis:2789890 (2.6 MB) eth0 Link encap:Ethernet HWaddr 00:10:c6:cf:24:81 UP BROADCAST MULTICAST MTU:1500 Metric:1 Packets reçus:0 erreurs:0 :0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B) Interruption:18 lo Link encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 adr inet6: ::1/128 Scope:Hôte UP LOOPBACK RUNNING MTU:16436 Metric:1 Packets reçus:10629 erreurs:0 :0 overruns:0 frame:0 TX packets:10629 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 Octets reçus:2864386 (2.7 MB) Octets transmis:2864386 (2.7 MB) wifi0 Link encap:UNSPEC HWaddr 00-14-A4-25-69-31-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Packets reçus:34286 erreurs:0 :0 overruns:0 frame:3762 TX packets:7388 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:199 Octets reçus:3209979 (3.0 MB) Octets transmis:2959241 (2.8 MB) Interruption:23
I don't get how i am supposed to filter out these pseudo devices.
Jean-François told me about this bug, and I had a look too. Seems that I have the same problem too, didn't notice it as I never really used gnome-system-monitor. When downloading from Internet, I got ~6MB/s (I got a 50MBps link at home so that's pretty much the max) and made sure I wasn't downloading anything else (the only other thing running there and using network are xchat and pidgin). While netspeed_applet gave the good value (it will only use one interface) gnome-system-monitor gave me twice my download rate. I have a bridge setup on my computer which I use to let virtualbox systems access my local network, which makes my traffic being shown on eth0 (the physical address) and br0 (the bridge). I'd suggest for you to only compute sum of network interfaces which have either an IPv4 or an IPv6 address, this way my eth0 and Jean-François' wifi0 wouldn't be accounted for, and the calculation should be then correct. You can always let the user choose to have all interfaces being accounted for, however I doubt it'll be useful to anyone (by the way I think there's a way to know if an interface has "any address" allowed, and not only IPv4 and IPv6, who knows when and who will use a different protocol, and there's already a lot of protocols supported by ifconfig, including unix, inet, inet6, ax25, netrom, rose, ipx, ddp, ec, ash and x25.
Created attachment 112333 [details] screenshot: gnome-system-monitor disagrees with wget
Created attachment 112337 [details] [review] Simple partial fix for gnome-system-monitor: ignoring interfaces without addr This patch will ensure gnome-system-monitor ignores interfaces without any IPv4/IPv6 addr, or those with only a "link" IPv6 addr. A real fix will require from gnome-system-monitor to always monitor each interface, and only include the active ones in the calculation while being able to compute average speed without causing a peak when one interface switches from "down" to "up" (or from "no addr" to "I have an addr" state). I don't really want to get involved too much in this as I don't know how the initial code of gnome-system-monitor was made, however managing a list of interfaces state using a std::map shouldn't be that hard. The main problem is to keep speed calculation consistent.
I tested the patch by Mark on my system, and it indeed now calculates the speed correctly.
Why would you skip scope-local links ?
Because every single connected interface on a system gets a link scope IPv6 addr, and aren't usually used to do data transfert. For example if you have two interfaces and a bridge, you get 3 IPv6 link scope address. By the way, link-scope address aren't usually used. On a LAN, if you want a private IPv6 network, you'll get address on "site" scope. If you have an IPv6 router and want each local system to get an internet IPv6 address, that'll be "global" scope addresses. Basically, you usually don't have to care about interfaces which just own link scope IPv6 addr, that's the same as not having anything.
http://svn.gnome.org/viewvc/gnome-system-monitor?view=revision&revision=2442 http://svn.gnome.org/viewvc/gnome-system-monitor?view=revision&revision=2443 This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.