ut creates way too much overhead

[bitburglar]

I say this because it's constantly showing +-50% overhead on whatever limits I set. like 16kB cap shows 24kB global, 24 shows 36, etc., before getting 1.8 it used to stay around the 10-20% usual expected. this is 1.8 build 11813, off a 8/512 cable connection, all seeding through private trackers with 6-12 or so active torrents. so no 1000's peer public swarms downloading going on here, mostly outbound traffic.

-no auto upload

-no dht

-no upnp

-few rss feeds

-global max halfopen 48

-net.outgoing_max_port 2048 (shitty router, ut does not obey this anyway)

-bt.connect_speed 16

-net.max_halfopen 24

-bt.multiscrape 1

-bt.prio_first_last_piece 1

-bt.scrape_stopped 1

-bt.set_sockbuf 1

-gui.bypass_search_redirect 111111111111111111111111111111111111111

pex is not very active lately either, was there a change in the way this works? trackers that I used to see alot of exchanged peers in now I hardly ever, even with plenty of ut/az clients.

[thelittlefire]

Well... Ctrl-G speed settings? Those ... Advanced settings are all irrelevant except for net.max_halfopen which should not be > 8.

[Firon]

Set halfopen back to 8 and upgrade to 1.8.1.

[bitburglar]

I don't think they're irrelevant since they all have the potential to change the amount of overhead generated. speed settings I don't see how they could be relevant unless they've been changed to something drastic, if I have described what my client's workload is. upload limit is changing all the time depending on what the rest of the system is doing, like gaming or downloading. max connections/torrent 40. max active torrents 12. upload slots 4. max global connections 360. max active downloads 3.

and I would like an explaination for why you think halfopen should not be > 8.

k firon I will try that

[thelittlefire]

Because it is unnecessary and creates overhead. LOL

DHT is periodic overhead, RSS is regularly-spaced download... not overhead. Scrape_stopped is the same as an announce, and only provides excessive overhead when you've got 1000s of torrents loaded. If you're only running private torrents why do you bother? The private torrents should be queued and those queued torrents are already scraped at the same interval as the expected announce to rotate your active queue.

What program are you using to measure this overhead?

[bitburglar]

global and application overhead is measured through a bunch of things like firewall and system perfmons, this is xp sp2 btw.

I don't queue much because the trackers I'm on have many more seeders than leechers, since they are private with ratio limits, so the rate would not be constant and keeping torrents queued would take much longer to finish.

[Switeck]

Firstly, if you don't use DHT, don't bother forwarding UDP packets from your router to your computer.

Secondly, a torrent may have lots of very aggressive peers/seeds that retry ips very often. These too create some overheads on your end even if you have global/per-torrent connection max set low. The only "control" you can have over this is to stop running some torrents or firewall uTorrent so at least it doesn't have to constantly send back "at max connections" messages. And even then it will only reduce download bandwidth used marginally...until days pass and peers/seeds leave the busy torrents.

Max speed settings in uTorrent is for how fast the files transfer, not how much bandwidth it takes them to transfer. The more upload slots are used, the higher the overheads for that get.

Half open connection limit in uTorrent also serves to increase overheads for limited benefit, especially if uTorrent is not firewalled.

[bitburglar]

just to update, after going to 1.8.1 and keeping halfopens at 8 I see no change in the upload overheads I am seeing. an interesting observation though after setting net.calc_overhead to true is, no change when only uploading, but behavior is much more stable like pre-auto uplink versions while downloading. why does it only do this while downloading? I realise that's when you have the most overhead with bt, but it's so drastically different from upload only, that the program subtracts from your global limit, *and* that mysterious 50% load dissapears.

there are things different with peer management and bandwidth calculations ever since auto-uplink was introduced, this is one of the reasons why I held off on upgrading. it's a feature that experienced users don't need and it seems like it's affecting stability whether we use it or not.

[thelittlefire]

Your problem is isolated, sorry

So you're saying you increase your upload limit TO the capacity of your connection and enable calc_overhead. If you do not have "automatic" upload enabled, that code is disabled. I'm not seeing a connection; correlation does not equal causation.

Could you elaborate what you consider "peer management" changes? I'm interested what changes mentioned in the changelog you think are relevant and well, your theory about what they left out of it

[Switeck]

bitburglar,

Have you tested bandwidth used on a torrent with few peers+seeds...with EVERYTHING else disabled, even going so far as using a different ip or port in uTorrent so old traffic isn't added in?