Upload speed drops

[ciaobaby]

that utorrent protocol is multithreaded

No idea, uTorrent is closed source so we have no access to find that out for sure. But you can use [url=https://technet.microsoft.com/en-us/sys ... 96653.aspx]Process Explorer{/url]  to examine what threads are active and what process is using or waiting for those threads to complete.

[ciaobaby]

Oh and!


Be prepared for seeing all the things you didn't know even existed that are running on your machine.

[KitKat]

[quote="ciaobaby"]
Process Explorer
[/quote]
I prefer the layout/options available in Process Hacker but its the same thing really.

[quote="qbi"]
When creating torrent with utorrent with checked "Disable Windows caching of disk reads and writes" there is no speed drop. Is this mean that utorrent protocol is multithreaded?
[/quote]
utp, the transport protocol, by definition cannot be multithreaded.
utorrent, the bitTorrent client is multithreaded (kind of) it uses seperate threads for downloading/uploading/management.
libtorrent, the library responsible for all torrent related jazz including(correct me if wrong) the actual torrent creation process is single threaded.

I cannot replicate the drops you're getting when you're not doing something with the client, i CAN replicate the one where creating a torrent causes speed to drop, this is a libtorrent issue


Here are more suggestions as to why your speed could drop when you're doing absolutely nothing to affect the PC.
1. CPU choked trying to do something (.net optimisation for example..) and it took a millisecond to recover, during that 1ms period your download&upload hit 0 causing the graph drop.
2. HDD needs a defrag as parts of whatever you're seeding are not sequentially located causing a slower read rate than what is optimal.
3. A piece your seeding to a peer accross the world completed and the speed drop was caused by your client waiting for him to ask for the next piece (latency issues..)
4. Peers completing the torrent and your client looking for a new peer to seed to.
5. Getting choked by peers because they connected to a "fast" seed and your client is correctly keeping the connection alive for a while incase they need the next piece.
6. Antivirus scanning the file you're trying to upload causing it to lock and qbittorent to failing to send pieces til the scan finishes.


I do not know how you connect to the internet, i do not know whether your internet is stable(if its ADSL or a distance based technology it is NOT stable), i do not know whether you have old and slow HDDs or super fast brand new ones, i do not know the state of repair they are in, i cannot replicate the problem in a local test environment with a 150gb file seeded over a wired connection (wireless would drop for sure..), i CAN however track sporadic few millisecond drops in my own torrenting behaviour which i assign to network fault/cpu choking as i tend to run alot of testing applications in VM while i upload.

Frankly as it correctly recovers and doesnt drop you out for minutes/hours at a time is this really even a problem?
If it bothers you so much you can look around for other torrent clients (i would recommend having a look at tixati) and seeing if the same issue occurs in them as qbittorent.
The only possible issue i've seen in this thread appears to be libtorrent related and would be regarding the threads libtorrent uses when simultaneously creating a torrent and seeding/downloading..

/e:
To be frank, personally i don't really care much for speedgraphs as i've set qbittorent up in a way that isnt detrimental to my bandwidth.
I use a network monitor and system task to kill qbittorent after it uploads a certain amount in GB of data every 24/h so i dont accidentally seed myself over my 2TB monthly dataplan..
I dont really care HOW fast it uploads provided it eventually reaches the limit i've set for it and gets terminated.. if it doesnt reach said upload limit no biggie..

[qbi]

When creating torrent with utorrent with checked "Disable Windows caching of disk reads and writes" there is no speed drop. Is this mean that utorrent protocol is multithreaded?

utp, the transport protocol, by definition cannot be multithreaded.
utorrent, the bitTorrent client is multithreaded (kind of) it uses seperate threads for downloading/uploading/management.
libtorrent, the library responsible for all torrent related jazz including(correct me if wrong) the actual torrent creation process is single threaded.

Are that the utorrent threads you mentioned?

Here are more suggestions as to why your speed could drop when you're doing absolutely nothing to affect the PC.
1. CPU choked trying to do something (.net optimisation for example..) and it took a millisecond to recover, during that 1ms period your download&upload hit 0 causing the graph drop.
2. HDD needs a defrag as parts of whatever you're seeding are not sequentially located causing a slower read rate than what is optimal.
3. A piece your seeding to a peer accross the world completed and the speed drop was caused by your client waiting for him to ask for the next piece (latency issues..)
4. Peers completing the torrent and your client looking for a new peer to seed to.
5. Getting choked by peers because they connected to a "fast" seed and your client is correctly keeping the connection alive for a while incase they need the next piece.
6. Antivirus scanning the file you're trying to upload causing it to lock and qbittorent to failing to send pieces til the scan finishes.

1. Do you mean single CPU core/thread or all CPU cores/threads?
2. Defrag status
3,4,5. I'm seeding actively between 30-50 torrents. Isn't your suggestions relevant for seeding fewer torrents (1-5)?
6. Utorrent and qBittorrent are added in the antivirus/firewall rules. If that was antivirus problem why with utorrent not happens?

I do not know how you connect to the internet, i do not know whether your internet is stable(if its ADSL or a distance based technology it is NOT stable), i do not know whether you have old and slow HDDs or super fast brand new ones, i do not know the state of repair they are in, i cannot replicate the problem in a local test environment with a 150gb file seeded over a wired connection (wireless would drop for sure..), i CAN however track sporadic few millisecond drops in my own torrenting behaviour which i assign to network fault/cpu choking as i tend to run alot of testing applications in VM while i upload.

My internet connection is a cable. My connection is stable except when ISP equipment is broken (rarely happens). The cable from ISP goes in the router. The PC is wired connected to the router.
I have 2 old ST320082 (1% space free), 1 year old DT01ACA200 (4% space free), 3 months old DT01ACA200 (1% space free), 1 month old DT01ACA200 (40% space free).

If it bothers you so much you can look around for other torrent clients (i would recommend having a look at tixati) and seeing if the same issue occurs in them as qbittorent.

Tixati in some trackers isn't allowed. Do you have opinion about aria2(isn't typical bitTorrent client)?

The only possible issue i've seen in this thread appears to be libtorrent related and would be regarding the threads libtorrent uses when simultaneously creating a torrent and seeding/downloading..

Yes, seems libtorrent problems. You mentioned that you tried with 150gb single file. Can you try with several thousand files placed on different disks? I think the problem is that several thousand files seeded from 5 different disk and something with the cache wiping out.

2 days ago I switched back to utorrent. No drops and that aggressive noise.

[KitKat]

[quote="qbi"]
Can you try with several thousand files placed on different disks? I think the problem is that several thousand files seeded from 5 different disk and something with the cache wiping out.

2 days ago I switched back to utorrent. No drops and that aggressive noise.
[/quote]
I wouldnt need to, i can tell you from experience that qbittorent slows down significantly as soon as you get into large multifile torrents.
libtorrent checks the entire torrent is there/not corrupt when it starts seeding(correct me if wrong, it may only check the file the piece is in) swapping between large torrents on different HDDs would cause libtorrent to have slow disc reads.
That would lead to the bahaviour you've described.

utorrent doesnt perform as many validation checks (libtorrent/qbittorent checks EVERYTHING on start and when you do anything with the torrent)
its much easier on the harddrive.

I dont think qbittorent as a torrent application is suitable to your setup :/

[qbi]

Thanks for the replies.

[KitKat]

Hi, this build fixes a problem that leads to an overloaded network stack in the release 3.3.4 build.
http://builds.shiki.hu/temp/qbittorrent ... ue_5109.7z

Try that build of qbittorent 3.3.4 and see if it fixes your dropout issue.

[qbi]

Thanks. I'll try it and will write the result.

[qbi]

Unfortunately again there are drops. With seeding only one torrent there is no problem.

[YashKa]

god damnit

im having the exact same problem, at the 18 minute mark, my seeds go from 3.5 - 4 MIB to zero for 5 seconds or so then shoot back up again. what is with the 18 minute mark?!

desperately looking for a client to migrate to, been using transmission, was hoping this one would be it

been tearing my hair out over this... done everything possible from getting off my onboard and buying a new NIC card, drivers updated for everything, even flashing my mobo. poured over every setting i could find to no avail. was about to reinstall windows till i seen this post (seriously considering linux even though i have never tried it)

as same as qbi, When OS cache is disabled, rarely happens but still happens.... plus i get a bit of a performance hit unfortunately

sorry for the necro, but im going to keep an eye on this thread in case a miracle happens and the reason why this happens is found (and i bet its something so trivial and dumb....)

[Switeck]

If you have favicon enabled, gather country flags, resolve ips, high half open connection limit, and add LOTS of trackers to torrents...these may be updating at exactly the same time somewhere between every 15-60 mins.

If you're on Windows, Process Monitor and/or TCP View (By Sysinternals, bought out by Microsoft) may reveal what's "hitting" at the 18 min mark if you look closely enough.