Q:Bandwidth limitation fails? A:Lower number of connections

[Ux64]

I have been wondering why my net is slow. Until I noticed that Deluge is using twice the amount I have set for it. This is especially true for upload. I haven't noticed this problem with download speed limit.

Upstream usage:
Upload limit: 40 KiB/s
Deluge shows uploading: 32 KiB/s
Network monitor shows deluge using 88 KiB/s.

That's why I also were wondering why almost always upload doesn't meet the limit. But actual upload is twice what's shown.

Interesting. Can someone also confirm these observations.

- Thanks

[yobbobandana]

I had been worrying about this a little because on the torrent details tab I always have "total data uploaded" increasing twice as fast as "uploaded this session". For example, I have for the upload stats on one torrent: 95.2MiB (44.7MiB), just from a single session.

But I just double checked with the gnome netmon applet and it seems to be the larger value that is wrong. Ratios and upload speeds seem to be caluclated correctly, so I can't confirm that the speed is double what is reported, just that something's off with my total data uploaded.

I'm running 0.5.6.2.

[Ux64]

Warning, this post is long and inconclusive. But if you want to read my speculation feel free.

But I just double checked with the gnome netmon applet and it seems to be the larger value that is wrong. Ratios and upload speeds seem to be caluclated correctly, so I can't confirm that the speed is double what is reported, just that something's off with my total data uploaded.

I just updated to latest version. I'll check if my problem persists.

About netmon application. It seems to be working ok (afaik). Because when it reaches my network max upload bandwidth I see immediately high latency increase. Which clearly points out that real maximum bandwidth have been reached. And in my opinion 50% of network can't be stealth traffic like DHT traffic which (might) not be included when checking torrent file transfer traffic quantity. And I know that my upload bandwidth is quite exactly 88 KiBytes/s.

Or could other "peer communication" might use that much ~30-40% of bandwidth? It reminds me from Gnutella times. More than 95% of network traffic was p2p coordination traffic, searches, results, pings etc. And only 5% was actual data because of (very) bad protocol design.

Download bandwidth is processed correctly in my mind. There seems to be difference in values. But netmon doesn't update those values too often. So it's not exact. Yet another though is that if DHT (or what ever) is using about 30 KiBytes/s of bandwidth in and out, it's not so clearly visible on download side because I got a lot more bandwidth on that side.

I might need to confirm this by setting upload and download both to 10 KiBytes/s and see what happens.

Full stop, all torrents paused. DHT seems to be using something like 2 KiBytes/s (on average) both, upload and download bandwidth.

First I also thought that "per torrent bandwidth" plugin might possibly cause something like this. But now it seems unlikely.

I rechecked, when deluge shows upload of about 65-70 KiBytes/s, my network latency to DSLAM bounces from 4 ms to over 200 ms. And I know that my upload bandwidth is more than that.

Sorry to say, it might be about files I'm downloading or what ever. But I couldn't get any conclusive or confirmed status with my test. So I could say that I'm sure it works this way. Except it still looks using somewhat more bandwidth. It might be netmon feature. But that getting upload always capped (by real bandwidth) before deluge shows it should be reached tells that something might be wrong.

But this was good (self) discussion. I hope someone with better tools can confirm or deny this "feature".

Deluge 0.5.6.96, Ubuntu 7.10 GG 64bit.

[yobbobandana]

Come to think of it, have you tried lowering the number of allowed connections? I probably only had around 100 when I tested, but you're maxed out at 450.

[Ux64]

Come to think of it, have you tried lowering the number of allowed connections? I probably only had around 100 when I tested, but you're maxed out at 450.

Nope, I haven't tried that. I'll try it. It might lower overhead. Let's see what kind of results I get.

Quickly I wound't think it could cause that large difference, but it's still possible that it is reason for that.

-- You got the point, thanks --

It seems to solve the problem. With 100 connections, about 10KiB/s is wasted on coordination traffic. With more connections naturally more bandwidth is also wasted. So bittorrent nodes communicate a lot to each other even if data isn't being transmitted. Naturally with ~450 connections it'll make about that 45KiB/s which I was talking about. And on download side that amount was non noticeable with my speeds.

-- Next question --

Then there is yet another question. In efficiency about selecting peers to keep connected. I have three files one which is ok, and two which are "stale" i mean they're only 70% avail and I have already downloaded 70%. And there are no peers sending to me or downloading from me. Still deluge uses quite high number of connections tied to that file. And all connections are idling.

Next question discussion is here:
http://forum.deluge-torrent.org/viewtop ... 3766#p3766