2.0.1 seems a bit lazy finding peers

[Vladmoz]

Hello gentlemen,

I've been using UT for quite a while and always been tending to use the latest versions. What I've recently seen is that all new betas (above 2.0) were abit slower in finding peers. I guess adding an "O" to the status bar stands to your decision to minimize overhead of the traffic obviously added by the network protocol.

I'm running probably a strange and hardly typical environment. The reason behind that is that there is no much good ISPs around here, but let me be short and exact here.

I'm using 3 ISPs in the following configuration.

1. 4G USB radio modem connected directly to PC via USB (i.e. appears as a "local area connection #6")

2. Routed connection with gateway address 192.168.1.1.

3. Routed connection with gateway address 192.168.1.2.

To use UT in this configuration I put a set of static routes (no default gateway set) to my XP SP3 ENU, fully patched:

route -p add 1.0.0.0 mask 255.0.0.0 192.168.1.1 metric 5
route -p add 2.0.0.0 mask 255.0.0.0 192.168.1.2 metric 5
route -p add 4.0.0.0 mask 255.0.0.0 192.168.1.2 metric 5
route -p add 5.0.0.0 mask 255.0.0.0 192.168.1.1 metric 5
route -p add 7.0.0.0 mask 255.0.0.0 192.168.1.1 metric 5
route -p add 8.0.0.0 mask 255.0.0.0 192.168.1.2 metric 5
route -p add 10.0.0.0 mask 255.0.0.0 192.168.1.2 metric 5
route -p add 11.0.0.0 mask 255.0.0.0 192.168.1.1 metric 5
route -p add 13.0.0.0 mask 255.0.0.0 192.168.1.1 metric 5
...

This all means each ~1/3 of addresses goes through ISP1 (route 1.0.0.0 -> 192.168.1.1), another ~1/3 goes through ISP2 (route 2.0.0.0 -> 192.168.1.2) and finally ~1/3 goes through local USB modem ISP3 (i.e. no route for 3.0.0.0 to anywhere).

In such configuration 2.0.0 compared to 2.0.1 seems to find peers in a more appropriate way, and keeps finding em in a more consistent manner. With 2.0.1 in turn I frequently run into a situation where the total speed looks like around 30% of expected. Yes, I do realize we are speaking of torrents. But a simple restart of UT rises the speed to fully expected in like a 2-3 minutes.

I've checked on 3 heavy concurrent torrent downloads with volume 2.5GB, 4.5GB and 8GB respectively and 50-100 seeds + 200-500 peers on each.

A quick UT restart changes amount of connected seeds from 2-3 to 7-10 for each download, while speed rises by 50-200%. I think it just speaks for itself.

This all makes me think there is certain issue with the current protocol implementation (which probably is very specific to my unusual environment).

Finally, I'm not demanding a fix, just would like to let you guys know of that. If that is corrected, it would be just great, though I doubt a lot of people have issues like that.

Thanks.

Vlad

[Switeck]

uTorrent is poor at best at working with multiple internet connections at once.

You'd need to run 1 uTorrent client for each internet connection to test each to determine if they're having connectivity issues.

[Vladmoz]

Thanks Switeck for your reply.

Honestly this story lasts for quite a while, and I'm actually CBA to repeat it from scratch with an appropriate level of testing, but here is a brief summary of what I remember using UT in similar setups:

1.9 (or probably 1.8) looked totally unusable in such cases (it did not even show downloads which came through multiple gateways).

2.0 had this worked out and was quite good in it.

2.0.1 does not have "oh no" issues with it, but still loses the game to 2.0.

Probably I failed to ask the proper question in the initial post... so the question is:

Are there any plans to do something with this in 2.0.1 and above or the best suggestion is to stick to 2.0 where things were pretty much fine with that?

PS. In times when it was totally unusable in such configuration I used to run a virtual machine with another UT instance to download stuff from internets using different gateways, while 2 UT instances just exchanged parts they downloaded via LAN and things were relatively settled besides overhead added by them downloading the same parts and eventually "forgetting" of each other.

[Switeck]

Do check that uTorrent is getting all incoming connections.

If the packets don't make it to uTorrent, uTorrent may not be at fault.

Packet types are an issue as well...regular TCP, uTP, native IPv6, and Teredo/IPv6 (encapsulated in UDP IPv4) -- you might not be getting all kinds.

[Vladmoz]

Hello Switeck,

Thanks for reply.

Well this is a good question. I'm pretty sure it gets em all or almost all at least via IPv4. I'm running in a totally IPv4 environment. My XP SP3 ENU is not IPv6 enabled and routers are not set up for IPv6.

The picture below shows my setup:

As shown on the picture I only doubt my XP gets em via USB modem, but it does not mean I should have that low connection speed anyways. The remaining 2 ISPs provide much more each individually. I just run a connectivity test and it went fine, though it might be using just 1 ISP (which is expected)

So OK I do run UT and see things similar like this:

Then some time comes and I see something like this:

I guess you would ask why on the second image the download total is lower than on the previous. I'll be honest, I took the second screen later than the previous, but I did not disconnect UT or any of the ISPs. This time I did not reproduce the issue (it was just a temporary speed fall, though I have no idea why -- I doubt ALL 3 ISPs failed, this is quite unbelievable) , just shown how it might look (and honestly if we speak of speeds, it DID work like that previously and for a really long time).

Well OK some time passes and what we see here:

Then a quick uTorrent restart and the picture changes to the following:

So that's it and thanks for reading a wall of text.

[Switeck]

Your networking may cease to be forwarding the incoming ports partway through your tests.

You may also be experiencing various uTorrent bugs concerning speed/connectivity.

Please test with just 1 (the "best") internet connection forwarded to uTorrent.

[Vladmoz]

Hello Switeck,

Thanks, I got your point. I've just run a UT built-in connection test using just USB modem and it proved my expectations: port forwarding is not working on it properly. And I'm honestly clueless how I can setup it properly (I'm not an admin, but I can say for sure this is not Windows firewall blocking it).

Honestly having 3 ISPs at the same time is a pain in the ass, but since none of them individually is satisfying, this looks like the only viable option for me.

On another note, I've done another test recently: I had UT running and started downloading another 1.5GB torrent which now shows ~560 seeds and ~2500 peers. UT started downloading it immediately and in a 2 minutes showed speed of 35 kB/s. After a simple UT restart the speed changed to 300 kB/s within a minute.

So my understanding is that upon startup UT does take certain actions which it does not take when is up and running. Probably it has certain settings for that which I'm not aware of?

Thanks for any advice of what might help in this situation.

PS. I also don't see a problem implementing an application which would restart UT say each 30 minutes (which I think would be simple 20-30 lines of code in C++ or plain C, while most of them could be copy-pasted from MSDN samples), but if there is any more graceful solution for that it would be just great.

[Switeck]

uTorrent is *NOT* suited at all for multi-home environments.

At best, it can mesh with multiple copies of itself each running on 1 internet connection each and linked via local loopback. They should all use separate ports just to be on the safe side.

Also, don't have them download the same torrents at once unless you're an expert in file access denied locking issues.

[Vladmoz]

Hello Switeck,

Once you mentioned "local loopback" in your reply I assume you are speaking of configuration where several instances of uTorrent are running on the same single Windows. The idea looks really good, though I don't know how it can be done technically. If you could advise it would be great. I'm going to configure the setup and see how it works for me.

1. How do I run 2 or more instances of uTorrent on the same PC? I was under impression it has a restriction to just 1 instance per PC running at the same time. I RTFM-ed /RECOVER option in the help file.

2. I already said I'm not an admin so I have no idea how to direct different instances of uTorrent via different gateways on the same PC. Could you please advise? Luckily I have 2 network cards, both connected to both routers, and another one is added by the USB modem as a virtual network device. I'm going to configure 2 network cards to use different IPs and different gateways and tell 3 instances of UT to use IPs of the appropriate adapters via net.bind_ip and net.outgoing_ip advanced options. Before doing it I'm also going to read "How to change the binding order of network adapters in Windows XP and in Windows 2000" article from Microsoft. Let's see how it is going to work out...

Thanks in advance.

PS. To solve file access denied issue I assume I can put configuration files (specifically dht.dat, resume.dat, rss.dat and settings.dat) to folders where several instances of uTorrent.exe are located and for each instance I can save files being downloaded to separate locations so they don't disturb each other downloading the same thing at once.

[Switeck]

Yes, to solve file access denied issues you'll need to save multiple copies of downloading torrents.

However for seeding only torrents, only 1 copy is necessary, just have all the uTorrent clients point to it.

[Vladmoz]

Hello Switeck,

I've configured the environment as described in the previous post with 3 UT instances and it looked like this:

1. USB modem connection does not have a static IP (it receives a new one each time it connects to ISP) so I set metric value 5 for it (as Microsoft describes). UT instance supposed to work over it did not have a static IPs set up and I assumed it would choose the first network interface from the list.

2. LAN interface #1 (metric 30) with IP 192.168.1.13 was pointing to gateway 192.168.1.1 and the UT instance supposed to use it had advanced IP settings to use IP 192.168.1.13.

3. LAN interface #2. Similar to LAN interface #1, but just replace local IP 192.168.1.13 with 192.168.1.14 and GW IP 192.168.1.1 with 192.168.1.2, and metric set to 60.

OFC I used different ports on all of instances of UTs (running from different folders OFC). All persistent routes I used to have before were of course deleted, and I had several Windows reboots in between to make sure the experiment is relevant enough.

Sadly, it all went fail. At least the result is much worse than I used to see with my previous configuration, to which I have already rolled back and still see the same things as I used to see before an attempt to use 3 UTs. I also rolled back to UT 2.0 build 18488.

The resulting issues are:

1. The normal sum of speeds for all 3 instances is much, much below expected. And I'm not sure how I can check which instance uses which network interface (and whether they all don't just use 1).

2. Syncing downloaded data between them is very inconsistent. I.e. having even a big download (30 GB) with 4 MB parts might cause em sync when certain of them did download 20-30 MB or even more. Probably they did download the same parts, but it does not affect the performance from my understanding -- it's just a question of whether this is an issue with the software or a level of my luck.

3. The most important one. After syncing downloads via local loopback (at really high speed) they start to keep actual downloads at a very poor speed. Say normal speed (for me per one ISP) would be like ~100 KBPS, then sync speed 5 MBPS, then they resume download from internet at 0.5-10 KBPS. I'm not sure, probably this is a certain speed calculation issue (or specifics), but looks very frustrating. When I see the speed of a total 5 KBPS for all 3 UTs summed up, while I expect to have at least 200-300, it is somewhat I would not like to see actually.

This is basically how the experiment went.

Thanks for your advices and hope to see a newer version of 2.0.1 which I would favor to 2.0 and thanks for all your good job to make this great product work. I know, the post was probably quite unpleasant, but I also do work in IT and I have a certain understanding of how thing go afterall. Beta is beta.