Page 1 of 1

Some observations/questions on BitTorrent downloads/uploads

PostPosted: 21 Nov 2010 19:11
by hjensen2
Hi,

The other day I downloaded OpenSuse 11.3 both the x586 and x64 version dvd's (4.05 and 4.18 GB) and the Opensuse 11.3 LiveCD (686 MB) together with the Ubuntu 10.10 both the x386 and the amd64 versions (693 and 694 MB). 5 files in total at the same time.

When I put full throttle to the network connection (3 Mbyte/s), the Shareaza was using one core 100% and there were those "network core overloaded" messages in the log, and it downloaded with about 1.5 Mbyte/s in total.
When I turned down the network speed in Shareaza to 1.3 MByte/s the "network core overloaded" was no more, and the CPU load dropped to "only" 90% of a core.
That state lasted until the last OpenSuse was downloaded, then the CPU usage was down to the normal 1-3% again.
I just wonder why a download of a big file takes that much CPU power.

The computer is a I7 2.6 Ghz /12 GB 1.3 GHz Ram.

Then something on BitTorrent upload, 1 - why are the upload lines rotating in the GUI ?
2 - As only very few uploads are more than 15 kBytes/s, why can't I set the number of uploads per file to more than 10 ?
With the 5 files the upload speed very seldom is more than 500 kBytes/s (My max is between 25 and 30 Mbit/sek)

Maybe there should be some 56k modem, middle, and high speed internet connection templates to choose from.
The one I got is the cheapest and slowest from my ISP !!! (It is also possible to get a 50/50 or 100/100 Mbit/s line)

NB! This is on the 2.5.3.0 Release 32-bit r8366 version

/Henning

Re: Some observations/questions on BitTorrent downloads/uploads

PostPosted: 22 Nov 2010 18:55
by ailurophobe
Shareaza has some problems with fast connections since it is older than modern high speed home connections. You can try going to advanced settings and increasing Bittorrent.RequestSize to 64. I randomly guess that would make Shareaza use larger requests when downloading which should mean it makes fewer requests per second -> less processing. Let us know if that helps, since if it does it might make sense to give fast connections a faster default on this setting (and maybe the similar settings for other networks).

Re: Some observations/questions on BitTorrent downloads/uploads

PostPosted: 22 Nov 2010 19:48
by raspopov
"Network core overload" happens when Shareaza spend more than 250 ms trying to access any of global synchronization objects e.g. host cache, upload/download core etc. when new BitTorrent request should be processed and was dropped instead. Try to reduce downloads/transfers number.

Re: Some observations/questions on BitTorrent downloads/uploads

PostPosted: 23 Nov 2010 20:51
by hjensen2
Thanks.

I increased the Bittorrent.RequestSize to 64 and now it downloads with > 2 MBytes/s on full throttle (set to max speed in the little network speed window).
And as long as the CPU load is below 100% on one core there is none of the "network core overloaded", as expected.

But as the download progressed the CPU load increased. starting from 1% and rising to 8% within 10 minutes. and still raising.
When the 2 ubuntu's got to ~87% their speed dropped down to a few KB/s in a few seconds. The CPU load was at that point 11% and still raising.
I paused all other downloads, so only those 2 were downloading. It did not help anything on the download speed. The CPU load for those alone 2 was 6%.
Then I paused those 2 for a few seconds, then I resumed them. That helped a lot. After resume, they got full speed and even resuming the other did no change on that.
The shareaza memory usage also dropped by that pause/resume on those 2.

So is there maybe an issue with the reassembly functionality ?

I had some more of those 680 MB downloads, and one more went into that a similar state. It had only 1-4 in downloading state, then a whole lot in choked and even more in requesting state. And the speed was 4 Bytes/s - 50 kBytes/s depending on the few in downloading state. And there was about 170 sources. It was the only download at that time, so it had all resources. A pause/ resume got it up speed again.

BTW. In the log, the messages is going so fast on the default loglevel, so I lowered the General.LogLevel to 0, but still get the red lines, where none seems critical.
[15:48:03] Handshake with 92.241.108.10 failed due to invalid data on the wire.
[15:48:03] BitTorrent coupling with 82.95.158.233 was dropped.
[15:48:03] BitTorrent coupling with 95.25.246.88 was dropped.
[15:48:03] BitTorrent coupling with 68.169.165.6 was dropped.
[15:48:03] BitTorrent coupling with 189.104.77.220 not accepted, a connection to this client already exists.
[15:48:03] BitTorrent coupling with 67.40.70.2 was dropped.
[15:48:03] BitTorrent coupling with 200.156.107.57 was dropped.
[15:48:03] BitTorrent coupling with 93.90.241.43 not accepted, a connection to this client already exists.
[15:48:03] BitTorrent coupling with 71.30.158.3 was dropped.
[15:48:03] Handshake with 80.101.173.84 failed due to invalid data on the wire.
[15:48:03] Handshake with 89.12.75.171 failed due to invalid data on the wire.
[15:48:03] Handshake with 83.135.111.66 failed due to invalid data on the wire.
[15:48:03] Handshake with 70.228.102.84 failed due to invalid data on the wire.
[15:48:03] BitTorrent coupling with 94.21.23.145 was dropped.
[15:48:03] BitTorrent coupling with 83.6.129.241 was dropped.

And it is mostly the LimeWire that gives the " invalid data on the wire", also as hub.

/Henning