qB "sucking up" one's bandwidth?

[zeomal]

That's how it was described by one of my friends, to whom I introduced qBittorrent. The friend tells me that is the ONLY reason, apparently, that keeps µTorrent the default client on the friends' (let's call the friend X) system. I tell X that all X has to do is set a download limit to X's torrents in qB, and that would solve the bandwidth sucking up issue.
But then X tells me that X wants qB to automatically understand when the network is being used, and when it isn't, and adjust the amount of bandwidth it uses accordingly. X says that X's family members are not able to even browse the web on another device (they all share the same Wi-Fi connection) when qB is active. Then I mention that it would be very difficult to include such a feature in qBittorrent (on the basis of my limited knowledge of programming).
And what does X reply to that? µTorrent already works that way! 

I tested that myself and found out that it was actually true. Even if a bandwidth limit was set, even simple tasks like casual browsing slowed down (quite literally) to a crawl. Can this problem be fixed? For all those of you wondering, the reason I did not incur this problem before it was brought to my notice is because I always paused qB before browsing, because my internet connection is VERY poor (around 60 KB/s). However, my friend has a connection of ~250KB/s, so I believe it's a qB problem.

[loki]

It might not be JUST speed issue but router being overloaded too, a few other options to try would be limiting global connections in addition to limiting the global upload speed by about 80-90% of tested speeds, not just rated speeds.

There's a "newer" feature in the speed settings to enable bandwidth management (uTP). This setting should have qB operate the same as utorrent, given the same program settings.
You can read a little about it here http://en.wikipedia.org/wiki/Micro_Transport_Protocol

[sledgehammer_999]

And I have to stress that you try less global connections and half-open connections(in advanced). Quite probably your router cannot handle the bt client connections AND the connections of the rest of the family members.

[Tomaso]

[quote="sledgehammer_999"]half-open connections[/quote]

Yes, yet again, this sounds like an issue with the half-open connections limit in Windows.

I got a message from a friend of mine just two days ago, where he decribed the excact same problem.
In fact, it became so severe that he couldn't even fetch mails.
What was particularly strange about it was that he was running Win7, which from what I've read isn't supposed to have this limit at all.

However, I told him to check with "TCP-Z" (a free tool) if there indeed was a limit..
and guess what?; the limit was set to 10!
Reports indicate that the only Windows version with a limit as low as 10 is Windows XP, so I made him check with another free tool called "XP-AntiSpy", and it told him the same thing; the limit was set to 10!

Even more strange, my friend ensured me that he was logged on as administrator, but when I told him to increase the connection limit by patching tcpip.sys, neither TCP-Z nor XP-AntiSpy allowed him to do so.

..Then he tried another free tool called "Universal Tcpip.sys Patch" (from the same developers that made TCP-Z) which finally allowed him to patch tcpip.sys:
http://deepxw.blogspot.com/2009/01/univ ... build.html
..but from what he told me, he was only allowed to choose a number of pre-set values.
Apparenly he was able to patch the limit to 250.

After rebooting, he ran in to another strange issue though..
On his desktop, he saw the message "Test Mode".
Anyway, after a quick Google search, I found several tips describing different ways of disposing of this message.
I'm a bit unsure as to which method he choose, but I think that he just applied the patch once more (described on Universal Tcpip.sys Patch's homepage), which made the message disappear after the following reboot.

And the ressult: the problem with qBittorrent sucking up all the bandwith: GONE!!

I checked the Universal Tcpip.sys Patch homepage, and the download links both seems to be dead.
So here's a working link:
ftp://ftp.dutaint.com/freeware/win-util ... 090409.zip
(Supported OS: Windows XP/2003/2008/Vista/7)

--

EDIT:
Of course, in the case of zeomal's friend "X", patching tcpip.sys will only fix the problem for his family members if they actually connect THROUGH his computer.
Is this the case, zeomal?

[sledgehammer_999]

The problem is that ?torrent doesn't need such a patch to work correctly.... :S

[Tomaso]

[quote="sledgehammer_999"]
The problem is that ?torrent doesn't need such a patch to work correctly.... :S[/quote]

It does on my system, and several others that I've encountered.
It doesn't just apply to qBittorrent, but torrent clients in general..
If I leave the connection limit at 10 (which is the default on WinXP), my connection comes to a complete halt, and I can't even browse the internet when a torrent client is running.
After patching tcpip.sys (I've got it patched to 500 connections right now) there is never any problem, and everything runs silky smooth!

[zeomal]

Of course, in the case of zeomal's friend "X", patching tcpip.sys will only fix the problem for his family members if they actually connect THROUGH his computer.
Is this the case, zeomal?

X has a router, and all the connections of other devices are through it. Not through X's computer.

There's a "newer" feature in the speed settings to enable bandwidth management (uTP). This setting should have qB operate the same as utorrent, given the same program settings.

I know about that. In fact, that's what I thought would solve the problem. My question is, should all the three options, viz. Enable Bandwidth management, Apply rate limit to µTP connections, and Apply rate limit to transport overhead be enabled? I think that the first two are enabled by default, so I'm guessing the third one should solve the problem? Does µTorrent have the third option enabled by default?

The problem is that ?torrent doesn't need such a patch to work correctly....

Exactly. One shouldn't go through doing all that Tomaso suggested (not because it's incorrect, but because it's kind of long). [No offense intended]

By the way, X runs Windows 7 64-bit.

[Tomaso]

[quote="zeomal"]One shouldn't go through doing all that Tomaso suggested (not because it's incorrect, but because it's kind of long)[/quote]

Well, it's only long because I wanted to explain things properly
The actual action of patching tcpip.sys isn't complicated at all.

I've heard the arguments that patching tcpip.sys isn't necessary a hundred times before..
Mostly from people who's only focus is the techincal theories surrounding the issue.
Usually, those of them that encounters the problem has to eat their words after increasing the limit, only to witness that the problem actually goes away completely!

However, in this case, the fact that X has got a router, and that his family members on different computers also are affected, indeed indicates that the problem lies elsewhere.

For those of you that experience a similar problem though;
To find out if the half-open connections limit really is the culprit, you can leave TCP-Z running (without patching anything)..
It will monitor your connections.
When the problem occurs, simply take a look at what it says.
..If the connections are maxed out (matching the Windows connection limit), then you've confirmed that the limit IS the problem.
Download TCP-Z here:
ftp://ftp.dutaint.com/freeware/win-util ... 0090409.7z

[zeomal]

[quote="Tomaso"]
Well, it's only long because I wanted to explain things properly
The actual action of patching tcpip.sys isn't complicated at all.
[/quote]
Yes. And I greatly appreciate that  . It's just that most users will be put off by the long explanation, and would give up before they even reach the end of the explanation.

[Tomaso]

[quote="zeomal"]Yes. And I greatly appreciate that  . It's just that most users will be put off by the long explanation, and would give up before they even reach the end of the explanation.[/quote]

LOL!
OK, fair anough.

For interested parties though, I guess that I should also add that some old and/or cheap routers might encounter problems if the number of half-open connections gets very high.
In such cases the problem will be similar; the internet connection might come to a halt.
At least, this is what I've read..
Personally I've never encountered any problems by patching tcpip.sys, nor do I know anyone who has.
Anyway, if anyone has got a router that can't cope, this can be counteracted by simply lowering the number of half-open connections in qBittorrent, like sledgehammer_999 described (3rd post in this thread).

By default, the number of half-open connections in qBittorrent is set to 50..
This comes into conflict with the default values on some OS, where the built in limit can be as low as 10!
Obviously, such a low limit is not very efficient when it comes to torrenting.
By patching tcpip.sys to allow a slightly higher number than 50 (say 60), you ensure that your system is compatible with qBittorrent's default settings (and probably every other torrent client's as well).

[loki]

Mine appears to be set at 10 also based on tcp-z, Win 7 x64... and from what I remember I never changed this value or patched my system and never had problems of slowing down browsing when running a torrent client (24/7), unless a rare occasion when I max download (currently set unlimited) AND max upload (to 90%).

And yes, qB is still set to 50.

The third setting, apply rate limit to transport overhead should only apply the compensation between 5-10% of your upload speed if I understand it's use correctly. If you already have set your upload maximum to 80-90% you shouldn't need to (also) enable this, it would/could actually cause you to NOT use more bandwidth.

Another comparison, this might not be the exact same but my router reports about 400 active IP connections at any given moment when qB is running.

[Nemo]

[quote="loki"]
Mine appears to be set at 10 also based on tcp-z, Win 7 x64... and from what I remember I never changed this value or patched my system and never had problems of slowing down browsing when running a torrent client (24/7), unless a rare occasion when I max download (currently set unlimited) AND max upload (to 90%).
[/quote]

I got the same loki . There is no limit with windows 7 so no need to patch. If you run tcp-z it shows 10 but its not patchable. Therefore when I was using xp sp3 that needed to be patched in order to work properly with any p2p app.

[Tomaso]

[quote="Nemo"]There is no limit with windows 7 so no need to patch.[/quote]
That's what I thought, so why on earth does it show that the limit is set to 10!?
From my experience, unlimited half-open connections should show up as either "0", or as a very high number.
I don't have Win7 myself, so I can't investigate, but it sure sounds a bit strange, especially when you take into account that all of those patchers specifically states that they're Win7 compatible.

--

EDIT:
OK, here's my best guess:
From what I've found out, the Win7 Beta releases DID have the half-open connections limit set to 10.
I'm guessing that when the patchers say that they're Win7 compatible, they're really just Win7 BETA compatible!
So, when they detect that the tcpip.sys file is unmodified under Win7, they just assume that the limit is set to 10.

Perhaps a bit far far-feched, but I'm just guessing here.

If this indeed proves to be the case, then the conclusion must be that when my friend experienced his bandwith problems, the problem was with his router and its inability to handle large amounts of half-open connections.
..And the fact that he hasn't run into the problem again after patching tcpip.sys is just by mere coincidence.

It would be nice to have my theory confirmed.

[Switeck]

I'm on Win XP Pro SP3 and have not patched windows to handle higher half-open connections at once.
I've set qBT to less than 10 outstanding half-open connections at a time.
I have very little need for more, especially since my old router (Linksys WRT54GL) pitches a fit when overloaded with connections anyway.

I have had other programs trigger Windows 4226 error message in Event Viewer ...But not very often.
"TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts." happened 2 times in the last 3 months.

I daresay the default maximum number of half-open connections value for qBT of 50 is both unnecessary for most users and excessive even for many that don't have an OS that limits to 10 concurrently.
A high max half-open connections is a cynical attempt to thrash through probably dead ips across multiple busy torrents, especially when the program first starts.
Once in steady-state operation, it serves mostly to quickly and continually retry the same dead ips over-and-over again.
If you are firewalled, a slightly higher max half-open connections can help...up until your router's NAT tables fill up or your firewall enters a "learning mode" and decides to block qBT due to "suspicious behavior resembling a DDoS attack".
A high max half-open connections can also aggravate bufferbloat.

[Nemo]

Exactly, it shows 10 but why? Its not patchable or anything. I did search all over the internet if it really is true that its gone as I had doubts too. The person who makes TCP-Z said the following in the comments section:

For NT6.x(Vista/Server2008/Windows 7)

In TCP-Z, if "Memory Limit" > 0, and "Create depth" = 0, it means current system is unlimite.

In TCP-Z, if "Memory Limit" > 0, and "Create depth" > 0, it means current system is limit.

In latese Win7, it is unlimited in default.

So its unlimited? Why the 10 then?

http://deepxw.blogspot.nl/2009/05/say-bye-to-half-open-tcp-connections.html

After that you get here: http://cwtuning.com/windows-7-tweak-wtTweakEnableConnectionRateLimiting.htm saying that there is a limit. I searched for the key named EnableConnectionRateLimiting but couldn't find it, instead I found EnableIPAutoConfigurationLimits with value 1. Same method found somewhere else:

Hi,

According your description I suggest that you could try to disable the half-open TCP connections limit, set the value of the EnableConnectionRateLimiting DWORD registry entry to 0 (0x00000000). To do this, follow these steps:

1.      Click Start, type regedit in the Start Search box, and then click regedit.exe in the Programs list. If you are prompted for an administrator password or for confirmation, type your password, or click Continue.

2.      Locate and then double-click the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableConnectionRateLimiting

3.      In the Value data box, type 0, and then click OK.

4.      Exit Registry Editor.

5.      Restart the computer.

But I can't find that register key anywhere. Some places say its gone and some other places say you need to patch. Seeing the dates of 2010-2011 seems its not that old posts, maybe before it changed to unlimited in the meanwhile.

Running Half Open Fix 4.2 gave this message:


So I guess there is nothing to patch . (Why the 10.. lol xD).