Task starting lag

[Exoth]

I'm using BitComet 1.31 64-bit on Windows 7 with Ethernet connection and Symantec Endpoint Protection with Comodo Firewall installed.

The bug is: the more connecting users from all enabled tasks I have, the bigger is lag of starting a new task. So even if I'm not uploading or downloading anything at all, but there are some serious amount of connecting users (one popular torrent is enough) I'm getting 30 seconds of lag when I try to start a task, both torrent or http. That is: in logs I see "Connecting to <some address>" and wait for 30 seconds after that.

[The UnUsual Suspect]

A connection doesn't changed to established until the peer responds to the attempt. If they don't have sufficient upload bandwidth, that response gets delayed and unfortunately this is the case more often then not, so if I understand you correctly, what your saying is similar to blaming your telephone when the party your calling takes 30 seconds or longer to answer the phone.

[kluelos]

When you start a task, your client tries to make a standard http connection to the tracker -- which is basically a web server that just does one thing.

Getting a reply takes time, and it takes more time if the tracker is overloaded. Trackers with a lot of popular torrents frequently never stop being overloaded, but the response time will vary all over the place.

This does not correlate with how many peers are connected to YOU. It correlates with how many peers are connected to the TRACKER, and how busy that tracker is, but the first is simply a sort of reflection of the second.

[greywizard]

"Lag" until what?

[Exoth]

No, if I stop all my torrent tasks, there's no lag at all. The download starts immediately. So that's exactly about how many users are connected to me, or rather how many users are connecting to me. As I already said, the problem is the same both for torrents and for HTTP downloads, so that's not about tracker lagging at all.

Even this work: I add a new task and it lags. The same moment I stop my torrents, the new task connects immediately without 30 second lag.

So it looks like an attempt to connect for a new task just waits for its order. And it's busy trying to connect to other peers for active torrent tasks.

Edited March 19, 2012 by Exoth (see edit history)

[Exoth]

Just to be clear one more example:

No torrents are enabled. I press ctrl+n and enter absolutely any valid address. So I enter "http://www.microsoft.com/en-us/default.aspx".'>http://www.microsoft.com/en-us/default.aspx". It downloads and shows me spent time of two seconds. The logs are:

2012-03-20 01:19:21 Task started.

2012-03-20 01:19:22 default.html created.

2012-03-20 01:19:23 Task completed.

A bunch of upload torrents are enabled. Download and upload rates are near 5 kB/s both (so no real upload is in process). I press ctrl+n and enter "http://www.microsoft.com/en-us/default.aspx".'>http://www.microsoft.com/en-us/default.aspx". It downloads and shows me spent time of one minute ten seconds. Actually at 1:08 it was 0% of download and at 1:10 it was already 100% of download. During these 1:10 I have absolutely no problem accessing "http://www.microsoft.com/en-us/default.aspx" from browser, so that's not a network problem too. The logs are:

2012-03-20 01:07:50 Task started.

2012-03-20 01:08:20 Start searching for mirrors...

2012-03-20 01:08:41 Found 0 mirrors .

2012-03-20 01:08:58 default.html created.

2012-03-20 01:09:00 Task completed.

Did it once more. And again 1:10.

2012-03-20 01:21:17 Task started.

2012-03-20 01:21:47 Start searching for mirrors...

2012-03-20 01:22:08 Found 0 mirrors .

2012-03-20 01:22:27 default.html created.

2012-03-20 01:22:28 Task completed.

If I reduce amount of upload tasks, the lag decreases. But usually it's enough to have just one serious torrent task active to have 30 second lag already.

Edited March 19, 2012 by Exoth (see edit history)