After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 518355 - misleadingly bursty network transfer rate
misleadingly bursty network transfer rate
Status: RESOLVED NOTGNOME
Product: system-monitor
Classification: Core
Component: resources
2.20.x
Other Linux
: Normal normal
: ---
Assigned To: System-monitor maintainers
: 532995 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-02-24 03:09 UTC by Ben Liblit
Modified: 2011-11-11 10:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ben Liblit 2008-02-24 03:09:29 UTC
System Monitor's Network History graph makes my transfer look misleadingly bursty.  I have a high transfer rate on one update, then no data at all on the next, then back to high again, and so on.  Every other update shows zero bytes transferred.  This does *not* agree with that actual arrival of data, which is much more smooth.  Unfortunately it makes it very hard to see what my real transfer rate is: the reported "Received:" rate also bounces back and forth between 0 and some much larger value.

I am currently using the default update interval: 1 second.  If I increase that to 1.5 seconds, then every fourth update is zero instead of every other update.  If I increase the update interval to 1.75 seconds, then the zeros go away entirely.  But simply slowing things down is not entirely satisfying.  I'd rather see reasonable updates at the reasonable default 1-second update interval.

Note that this problem affects both the System Monitor application and the panel applet.
Comment 1 Benoît Dejean 2008-02-24 18:12:43 UTC
Could you run something like:

for i in $(seq 1 10); do cat /sys/class/net/eth0/statistics/rx_bytes; sleep 1; done

while downloading ?
Comment 2 Ben Liblit 2008-02-25 02:09:40 UTC
Output from "repeat 10; do cat /sys/class/net/eth0/statistics/rx_bytes; sleep 1; done" is as follows:

1780775657
1780775657
1781426867
1781426867
1782079547
1782079547
1782730757
1782730757
1783381967
1783381967

So the bursty updates are coming from the kernel itself.  :-(

Note that data arrives in the downloading application at a fairly smooth rate.  I was seeing about 300K/s reported by my downloading application (wget) while the above numbers were being collected.

So this is clearly not system-monitor's fault.  But does anyone have a clue why rx_bytes would update so infrequently?
Comment 3 Benoît Dejean 2008-02-25 08:03:09 UTC
what about a tcpdump/tshark capture ?
Comment 4 Ben Liblit 2008-02-26 07:09:25 UTC
tshark capture shows data arriving continuously and steadily.  There are no 1-second gaps between packets.  This is consistent with observed arrival of data by the downloading application.  I reiterate my initial statement that data reception is not *actually* bursty.
Comment 5 Benoît Dejean 2008-02-26 08:11:35 UTC
Then you have to open a bug on http://bugzilla.kernel.org/
Comment 6 Ben Liblit 2008-05-03 21:56:26 UTC
Opened as <http://bugzilla.kernel.org/show_bug.cgi?id=10600>.
Comment 7 Gruys 2008-05-13 20:09:10 UTC
*** Bug 532995 has been marked as a duplicate of this bug. ***