Badly under-reports bandwidth usage.

Bug #428231 reported by Darxus on 2009-09-12
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Azureus
Invalid
Undecided
Unassigned
azureus (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: azureus

Limits set to 260 kilobytes per second down and 50 up. Reporting usage in that general vicinity. Over 3 minutes, /proc/net/dev reports 325.4 kilobytes per second down, and 73.1 up. That's 25% more for down, and 46% more for up than azureus is reporting.

I do currently have a bunch of active torrents, and I suspect the problem is less significant with fewer torrents = less overhead. But still wrong.

(Subtracted the 0.5 kB/s I'm seeing in /proc/net/dev with netstat -tuapn and route -n showing nothing. Weird.)

$ lsb_release -rd
Description: Ubuntu 9.04
Release: 9.04

$ apt-cache policy azureus
azureus:
  Installed: 3.1.1.0-4ubuntu1

Upstream bug: https://jira.vuze.com/browse/SUP-138

Javier Moreno (elpasmo) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, according to this report, you are not using the most recent version of this package for your Ubuntu release. Please upgrade to the most recent version and let us know if you are still having this issue. Thanks in advance.

Changed in azureus (Ubuntu):
status: New → Incomplete
Darxus (darxus) wrote :

Another random switch to invalid without testing, huh (bug #434979)? The version was current when the bug was reported, and the problem continues to exist.

$ lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

$ apt-cache policy azureus
azureus:
  Installed: 4.3.0.6-1

Changed in azureus (Ubuntu):
status: Incomplete → Confirmed
Javier Moreno (elpasmo) wrote :

Hi Darxus,

Neither the bug #434979 nor this one were random changes. I couldn't confirm it in my 10.04 with the system monitor so I asked and I changed to Incomplete and I thinks that's the right thing to do. Except that I should have written in my comment that I didn't see this issue in recent versions.

Anyway, tomorrow I'll try to confirm it in 10.10, but until then, I think the status should be set to New because only you has reported this bug and nobody else couldn't confirm it.

Darxus (darxus) wrote :

Yup, sorry, I forgot to verify that the status had been confirmed.

Changed in azureus (Ubuntu):
status: Confirmed → New
Javier Moreno (elpasmo) wrote :

I can't confirm it in a 10.10 2.6.35-24.42 i386 with vuze 4.3.0.6-1.

Have you tried to reduce the number of peers connected? It seems that this option has a direct impact in overhead bits. And I quote from http://wiki.vuze.com/w/Reduce_memory_usage

"Many users overestimate the importance of the number of peer connections since they think more peers = more download, but that's a misconception. Peers will only be willing to give data to you if you give data to them. Since your upload speed likely has a low cap, it is in your best interest to connect to only a few peers and send them as much data as possible, so they will reciprocate. More peers = more memory used + less available bandwidth due overhead of the BitTorrent protocol.
Generally 90-120 connections should be enough under most circumstances."

Can you explain also, step by step, how are you calculating your connection speed mean? I'm finding that's difficult to calculate.

Thanks in advance

Changed in azureus (Ubuntu):
status: New → Incomplete
Darxus (darxus) wrote :

I'm counting a total of 21 peers. And it should still report actual bandwidth used with many peers.

I got bandwidth used like this (script I wrote):

wget www.chaosreigns.com/code/dl/netload.pl
chmod +x netload.pl
./netload.pl 60
 dev rx mrx tx mtx dev rx mrx tx mtx dev rx mrx tx mtx
eth0 41.4/41.4 11.7/11.7 vboxnet0 0.0/0.0 0.0/0.0 wlan0 0.0/0.0 0.0/0.0
eth0 42.8/42.8 12.2/12.2 vboxnet0 0.0/0.0 0.0/0.0 wlan0 0.0/0.0 0.0/0.0
eth0 42.8/42.8 13.3/13.3 vboxnet0 0.0/0.0 0.0/0.0 wlan0 0.0/0.0 0.0/0.0

So that's: (network device) (receive speed)/(max receive speed) (transmit speed)/(max transmit speed) (network device)...

The relevant numbers are the second column: 41.4, 42.8, 42.8 - kilobytes per second. With azureus throttled at 37 kilobytes per second.

The argument to netload is the number of seconds per reporting period, so one minute.

That script is pretty simple, and at least 9 years old. It reads /proc/net/dev, which includes, for each device, bytes received and bytes transmitted since the last boot. The values wrap, I don't remember where.

If you find some other way of reporting average bandwidth for more than a fraction of a second, like this, let me know. The gnome panel System Monitor seems unsuitable due to very small sample periods.

I shut all my other network applications down for the test. Browsers can use a scary amount of bandwidth while doing nothing.

Thanks for taking the time to attempt to confirm.

Darxus (darxus) wrote :

If you don't want to rely on a script I wrote, you can do:

grep eth0 /proc/net/dev | awk '{print $2}' ; sleep 60 ; grep eth0 /proc/net/dev | awk '{print $2}'

Assuming your internet connection is through your eth0 device.

/proc/net/dev includes column labels so you can verify the second column is bytes received.

Subtract the values and you have bytes transmitted per minute. Devide it by 60 to convert to seconds, and divide it by 1024 to convert to kilobytes. So...

$ grep eth0 /proc/net/dev | awk '{print $2}' ; sleep 60 ; grep eth0 /proc/net/dev | awk '{print $2}'
18928602120
18931397743

$ bc -l
(18931397743-18928602120)/60/1024
45.50167643229166666666

45.5 kilobytes per second. (I have other stuff running, so not a representation of azureus usage, just an example.)

Javier Moreno (elpasmo) wrote :

Great script! (I'll bookmark it if you don't mind) Now I can confirm this bug:
10.10 i386 2.6.35-24.42 with vuze 4.3.0.6-1

Changed in azureus (Ubuntu):
status: Incomplete → Confirmed
Javier Moreno (elpasmo) wrote :

Confirmed also with last version of vuze: 4.5.1.0/4 az3

Javier Moreno (elpasmo) wrote :

I can't add a bugwatch to the upstream error so I link it here: http://forum.vuze.com/thread.jspa?messageID=234084

Javier Moreno (elpasmo) wrote :

Confirmed also in the last CVS version of vuze: 4.5.5.1_B36.

Javier Moreno (elpasmo) wrote :

Upstream error in Jira: https://jira.vuze.com/browse/SUP-138

description: updated
Changed in azureus (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Low
Javier Moreno (elpasmo) wrote :

Setting it to invalid due the response of the developers: https://jira.vuze.com/browse/SUP-138

Changed in azureus:
status: New → Invalid
Changed in azureus (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers