Alternate seeding options.

[Martin Levac]

Greetings,

I'd like a few more options for seeding when not downloading. Alt upload slots and alt connections per torrent.

ML

[Animorc]

Nothing else to say than that I think this is a good idea.

And it would not surprise me is Firon came up with a "implemented in the next beta"-comment as usual

[Switeck]

A simple extension of this idea would also apply to scheduler.

It seems really silly to retain the high number of upload slots and connections per torrent when µTorrent goes into a reduced-speed seeding mode or scheduled "limited" mode.

[Firon]

It already lowers the upload slots automatically based off your upload cap, Switeck

[Martin Levac]

This is what I do when I'm seeding. I run one torrent at a time, I set 20 connections max, I set 20 upload slots for a 100kB/s upload limit. All peers that connect to me and that I connect to get something from me until either my share ratio is reached or until I stop the torrent, whichever comes first. There are no peers that will just connect to me or that I will connect to that will wait for the connection to be unchoked. I play nice. That's why I want alternate upload slots and alternate connections per torrent when not downloading.

If I keep the same settings I use to download for seeding, I take up connections to other peers that serve no purpose other than to take up a connection on those peers. For example, I set anywhere between 100 and 500 connections per torrent and anywhere between 10 and 20 upload slots per torrent on a 60-70kB/s upload limit. I download only one torrent at a time so that's not a problem.

In fact, inactive connections to seeds should be terminated after a period of time to allow the client to look for active seed connections based on its network/torrent parameters. BitComet has a serious problem with that particular behavior, instead of terminating the connection when it has finished the file or reached its share ratio, it simply chokes it which is why we see many BitComet seeds doing nothing but sitting pretty at 100%.

Perhaps adding some sort of check for the seed's share ratio could be implemented to distinguish between those that still upload and those that have reached their share ratios and will not upload anymore. A peer checks the seed for its share ratio, if it's been reached, it immediately disconnects it and goes about looking for another seed that hasn't reached its share ratio yet. Even then, it would only be a patch for a flaw within the BT protocol that allows seeds to have more connections than active upload slots.

ML

[Firon]

Um, it disconnects any and all peers that are inactive for 5 minutes, seed or not.

[1c3d0g]

And that value is customizeable in Advanced Options as peer.disconnect_inactive (in seconds). Note: setting it to < 5 minutes will be ignored.

[Firon]

Technically, it's at 6 minutes. When one peer reaches 6 minutes, it disconnects all peers that have been idle for at least 5 minutes.

[Martin Levac]

That function doesn't distinguish between a peer and seed.

Then reconnects to whatever other peer it finds, be it a new peer or a previously known peer. That happens because the client doesn't distinguish between a peer that is choked and one that is unchoked until the end of those 6 minutes, then it forgets what it did. It happens because the client still has to fill his quota of connections regardless of whom it connects to. Round and round she goes.

Have you tried to seed a file the way I do? Look closely at what happens and tell me what you think. Compare that to what is currently happening when you download a file.

ML

[Firon]

Not quite, because it doesn't try to reconnect to those disconnected peers for 30 seconds. It also doesn't forget how much it downloaded and uploaded from said peer.

[Martin Levac]

peer.disconnect_inactive

It doesn't distinguish between a peer and seed.

uTorrent disconnects any and all inactive peers or seeds after at least 5 minutes of inactivity.

uTorrent doesn't remember if a peer or a seed was choked for those 5 minutes of inactivity upon reconnection to the same peer or seed. It only uses inactivity as the factor to consider if it terminates or maintains the connection to that peer or seed then it forgets about that fact.

uTorrent tries to connect to previous peers or seeds only after at least 30 seconds.

The point is that it still tries to connect to previous peers or seeds regardless whether that peer or seed choked the client for 5 minutes on the previous connection. That behavior is controlled in part by the network/torrent connections parameters, the client is forced to fill his connections quota with any connection.

What happens to the peer or seed that is choked permanently yet maintains inactive connections to peers? The client still tries to connect to it regardless of previous connections to that same peer or seed.

As I said, round and round she goes through the motions of connecting, choking, disconnecting, reconnecting, choking again, etc, all to the same seed (or peer) because it does not remember that the seed was previously choked.

That uTorrent already lowers upload slots when seeding based on my upload cap is irrelevant since I increase my upload cap when I'm not downloading.

Firon, are your arguments against or for the feature request? Did you try to seed a file the way I do it? There are no choked peers the way I seed a file, all peers get something from me all the time until my share ratio is reached or I stop the torrent, whichever comes first. What it looks like to the peers connected to me is that I am an active seed to which they remain connected until my share ratio is reached or I stop the torrent or until they are finished with the file and become seeds themselves, whichever comes first.

I want alternate upload slots and alternate connections per torrent when not downloading just like there is alternate upload limit when not downloading.

ML

[tumu]

What is this thread about?

1. having UT remember choking seeds/peers until idle timeout (for reducing connects to them)

2. having alternate settings for seeding torrents

?

[Martin Levac]

Alternate seeding options. That's what this thread is about and I realized today just how much I want this. I'm sending multiple peers less than 1kB/s on a consistent basis. Maybe these peers can't take or don't ask more than that for some reason, I don't know. I still want to send more to fewer peers and I want it done automatically so I don't worry about playing nice once I get the file myself.

Here's what I'm doing right now. Seeding three torrents, each of which have fewer than 10 peers connected to me on average. That's not my settings, it's just the torrents. Normally, I set 10 upload slots for one torrent at 100kB/s. This time with three torrents, it doesn't work as efficiently. I could just reduce upload slots now but what about when I'm only seeding one of them? I'd like some form of control on the global number of upload slots that automatically adjusts itself based on my preference. Let's say I want to give a minimum of 10kB/s per peer globally. Upload slots would automatically be adjusted per torrent if more than one torrent is seeding.

I read that uTorrent already limits upload slots based on upload speed by dividing it by 3. That's not enough for what I want to do. I want to be able to limit the number of upload slots globally even more and I want it to adjust itself according to the number of torrents I'm running. Global connections takes care of one detail but the rest just stays fixed unless I manually set them according to what's happening.

ML

[Switeck]

I read that uTorrent already limits upload slots based on upload speed by dividing it by 3.

Where is this stated?

[Firon]

Loooong ago, in some beta build. It takes your upload cap and divides it by 3 to get the max allowed upload slots on a per-torrent basis. Of course, this doesn't work so well when you have many torrents, but it's better than nothing. I believe that uncapped uploads are limited to 25 slots.

[Martin Levac]

I don't remember. I'm not sure but I think it's Firon that said something to that effect in one thread about speeds a while ago. I could be mistaken.

ML

-edit- nvm -edit-

I recently found out that making 20 connections and setting 20 upload slots doens't work too well. It has to do with some slots only getting 1kB/s or less because other slots get more than 100kB/s / 20 = 5kB/s. Now I do 25 conns and 10 slots, it's just better overall. Nevertheless, I still want those alternate seeding options to be able to do that automatically.