"Queued Seed" forever

[Timwi]

I am currently seeding 25 files. 23 are working normally. Two of them show "Queued Seed" and never actually start seeding.

It can't be the case that the tracker is down because all 25 files use the same tracker.

There are no messages in the "Logger" tab ("Log Errors" option is enabled).

What does "Queued Seed" mean, anyway? Why doesn't it just seed?

[Firon]

You can only have so many active torrents at once. When that limit is reached, the rest are queued.

[Timwi]

Why?? Why would the software artificially limit the number of files I can share via BitTorrent? That does not make any sense.

Also, why would the limit be 23 (of all numbers)? How do I configure this limit?

Also: I stopped all torrents, restarted µTorrent and started seeding them all again. This time I got three permanent "queued"s (instead of two, as before). Then I did this whole thing again and now all 25 of them are seeding. Clearly, the limit is not very constant?

[Ultima]

Because having too many torrents started simultaneously does nothing but (1) waste bandwidth for peer communication overhead, and (2) spread the upload rate too thin.

Preferences > Queueing allowed allows you to set the number of torrents, but you should leave the work to µTorrent via the Speed Guide. If µTorrent starts more torrents than it is configured to do without you forcing torrents to start, then that's because the torrents are transferring at less than 1KiB/s.

[Timwi]

I think there is a misunderstanding. The options you are referring to limit the maximum number of active connections (active uploads/downloads). There is no option (or none that I could find) that limits the number of files that are being seeded. Besides, clearly the behaviour that I've described exhibits a bug because whatever the limit is, it is not being enforced consistently.

To me, it looks like the bug is simply that some torrents remain in the queue forever.

[Firon]

No, you just don't understand the terminology. Torrents are not the same as files. Connections are not the same as uploads/downloads.

The queueing section is for active torrents. There is a limit because your upload is limited, and spreading it too thin is bad. Don't set limits that are too high. If say, you've got 30kB/s upload, you should run maybe 2 active seeds at once (µTorrent will start more queued ones until there are enough active ones, which means above 1kB/s)

[Timwi]

In other words, you seem to be suggesting that it is impossible to share more than just a handful of files? That's a bizarre philosophy for a file-sharing system...

[DreadWingKnight]

Considering that bittorrent is not a traditional p2p system, it doesn't seem as bizarre.

[Timwi]

"Tradition" is irrelevant. It means I cannot share as many files as I would otherwise, and therefore reduces the amount of files available in total and therefore reduces the quality of the overall network. If I can share 1000 of my files via eMule and only 25 of them via BitTorrent, then clearly the eMule network (eDonkey2000 for the pedants) benefits more. To claim that this is "by design" or "intended" is bizarre.

[Firon]

You really don't understand the difference between BitTorrent and traditional P2P networks like eMule. They don't work the same in how you share files. Go read up on the protocol.

[Timwi]

I am very familiar with the capabilities and the shortcomings of each protocol (BitTorrent and ed2k). Thank you very much. There is nothing in the BitTorrent protocol that says that you can't share more than n files.

[Firon]

You still don't get it. On eMule and networks like it, you share an entire library of files, and control upload slots for that. On BT, every torrent is like a new network, and the upload slot control is per-torrent, not global. So running too many will spread your upload too thin.

[Saribro]

I think there is a misunderstanding.

You are indeed misunderstanding.

The options you are referring to limit the maximum number of active connections (active uploads/downloads). There is no option (or none that I could find) that limits the number of files that are being seeded. Besides, clearly the behaviour that I've described exhibits a bug because whatever the limit is, it is not being enforced consistently.

The behaviour is easily explained. In the advanced options, you can set whether slow torrents (<1kiB/sec IIRC) are counted as active or not (default = not). So if you have set max 5 torrents active, 4 transferring nicely and 1 at less than 1kiB/sec, the queue will make a 6th torrent active. When the 5th torrent picks up speed, the 6th will be made inactive again.

The maximum number of active torrents -is- in the settings, and they are limited for good reason. The amount of connections and upload slots is managed per torrent, so the global amount of connections and upload slots is directly dependent on the amount of active torrents. Therefor, you need to limit the amount of active torrents to a sane value for your connection (determined by you uploadbandwidth), otherwise, the overhead from keeping too many connections open and managing too many separate datatransfers will leave little or no room left for actual sending/receiving of data, and you'll end up with a big bunch of torrents running at 0.7kiB/sec each, instead of a small bunch of torrents running at 70kiB/sec each.

Being connected to a peer does not mean by definition you are uploading/downloading with that peer. The amount of people you are uploading to is determined by the amount of upload slots, the amount of people you are downloading from is largely determined by those other people. And no, you don't need to be uploading and downloading to every peer you are connected to.

I am very familiar with the capabilities and the shortcomings of each protocol (BitTorrent and ed2k).

Obviously, you are not.

[Timwi]

Saribro, I am perfectly familiar with the protocol. You have not explained anything new to me, I already knew all this. The misunderstanding lies with you guys because you are all misunderstanding my original posting. Maybe I'm not being very clear, but I find it difficult to see how I could be even more clear. Maybe you get easily sidetracked and quickly forget what I said in the first posting.

I am not talking about uploads or uploads speeds. This has nothing to do with bandwidth, with "upload thinning", with uploads being active or inactive, or anything else you talked about. All I'm saying is that µTorrent is displaying the message "Queued Seed" forever for some torrents instead of switching them to "Seeding". I am not expecting that all the torrents start uploading. I am merely expecting that they become available to other users, since after all I am sharing them.

I am getting increasingly frustrated with the people in this forum, who apparently try very hard to blame everything on the user instead of realising that your software has bugs. As a result, I will be less inclined to report bugs in the future, so don't be surprised if your software won't be very popular because it is full of bugs which you all constantly try to explain away as "user error".

[DreadWingKnight]

User misinterpertation of protocol and client designs are NOT bugs.

I am getting increasingly frustrated with users who think they know the protocol and how it works, and yet demonstrate in their posts with their settings and connection information that they do NOT understand how it works.

When a user sets their settings so that each peer they're uploading to gets less than 1kbyte/sec would you call that user error or a software bug?

The queued seed state is a state that torrents are in where the number of torrents loaded exceeds the number of active torrents permitted.

Running more torrents than your connection can support (which you appear to be doing) will cause a big mess, not only in your own queue, but in the swarms for the individual torrents.

Are these torrents that are in a queued state having a higher ratio than the others in your seeding list?

[Saribro]

You have no seed goals set so that torrents can never finish seeding? As long as there are 23 (in your case apparently) active torrents, as you must have set yourself in the options (yes, it -IS- in there, thing Queue), the 24th or 25th will be queued (which means: will wait in line) untill a torrent ahead of it becomes inactive. Torrents can become inactive when they reach their seeding goal (ratio and/or time, both user specified) and finishes, when it is paused or stopped by the user, or when it's speed drops below 1kiB (in the default case with don't_count_slow enabled in advanced options).

A common case of torrents to drop below 1kiB/sec is poor settings that spread the bandwidth too thinly between active torrents.

Or perhaps you could just look up words you don't understand:

http://dictionary.reference.com/browse/queue

second entry.

[jt666]

@DreadWingKnight, Saribro

Let's see... I want to share, say, 100 torrents. I only want to maximize the chances that other people get these files (and speed), permanently all of them. That's the point of sharing, right? So...

Situation #1

I have 100 seeding torrents, first 23 is active, the rest is queued, obviously.

All of them have only seeds and no peers, so no data transfer occur (aside from scrapes), then suddenly some peers appear on 40th (now queued) torrent.

Question: Will µTorrent detect this and activate 40th torrent, putting one of non-transferring(preferably with other seeds beside me, and then, without peers) active torrents in queue?

Situation #2

I have 100 seeding torrents, first 23 is active, the rest is queued, obviously.

All of them have seeds and peers, so data transfers steadily, then suddenly all seeds dissappears from 40th (now queued) torrent.

Question: Will µTorrent detect this and start seeding 40th torrent, putting one of now active (preferably most seeded) torrents in queue?

As i see it, if both answers is ''yes" then great if no, then we have lazy (bad) design, not bug, here. Please correct me if i'm wrong.

[Saribro]

Yes on 1 if you have queue.don't_count_slow_ul/dl set true in advanced options.

Yes on 2 if you have queue.prio_no_seeds set true in advanced options.

Both are true by default, so, yes.

[DreadWingKnight]

Having 20+ torrents active may seem like you're trying to maximize the availability, but in practice it doesn't unless you have true 100mbit up (The connection being housed out of a datacenter, in Sweden or in Japan).

You have to take into consideration that the number of upload slots set in your preferences are per-torrent. Each torrent you have active ADDS that many upload slots to the number you already have. How much are you really benefiting someone when you're only uploading to them at maybe 100 bytes/sec?

In situation one, with queue.don't_count_slow_ul/dl enabled the torrent would still be active but wouldn't count towards queuing totals.

In situation two, with queue.prio_no_seeds enabled the less seeded torrent would get priority.

You have to keep in mind, if you're keeping more torrents active than your connection can sustain, situation one will become more and more frequent until you correct your settings.

[Timwi]

Many thanks to jt666! Apparently you know better than me to ask the right questions

DreadWingKnight:

I am getting increasingly frustrated with users who [...] demonstrate in their posts with their settings and connection information that they do NOT understand how it works.

The reason you think this way is because you have misinterpreted my postings and you are now reluctant to admit to yourself that I mean something wholly different. To be frank, your posts demonstrate this quite clearly, because you keep going on about the same thing (namely, upload speeds!) despite the fact that I've already said this is not what this is about. jt666 appears to understand the problem better.

Also DreadWingKnight:

You have to take into consideration that the number of upload slots set in your preferences are per-torrent.

If that is the prime source of the problem, then maybe this design decision should be revised?

How much are you really benefiting someone when you're only uploading to them at maybe 100 bytes/sec?

More than at 0 bytes/sec! But nevertheless, I repeat, this is not about upload speeds

with queue.prio_no_seeds enabled the less seeded torrent would get priority.

Even if it is in "Queued Seed" mode? Does µTorrent even know anything about the torrent's peers if the torrent is in that mode? (It sure doesn't display anything in the "Peers" tab.)

You have to keep in mind, if you're keeping more torrents active than your connection can sustain

If µTorrent can sustain only 25 torrents on my connection, but eMule can cope with 1000 shared files on the same connection, then eMule wins over µTorrent and the ed2k network benefits more than BitTorrent.

[DreadWingKnight]

You are trying to compare a downloader-supplemented download accelleration system (bittorrent) to a peer to peer network (ed2k).

Even if it is in "Queued Seed" mode? Does µTorrent even know anything about the torrent's peers if the torrent is in that mode? (It sure doesn't display anything in the "Peers" tab.)

scrape my boy, scrape

If µTorrent can sustain only 25 torrents on my connection, but eMule can cope with 1000 shared files on the same connection, then eMule wins over µTorrent and the ed2k network benefits more than BitTorrent.

How many upload slots are you running in emule I wonder?

Probably less than 30. Which means you're uploading to maybe 30 people.

With your settings, you could potentially be trying to upload to over 200 people.

The bittorrent protocol operates most efficently when a peer can upload an entire request chunk (16384 bytes) in a timely manner. 100byte/sec is NOT a timely manner for that much data (almost 3 minutes to get a request chunk).

[Switeck]

Having too many upload slots active at once as a result of too many active torrents at once violates the BitTorrent protocol. This is because TCP/IP flow control gets VERY BAD when dealing with sub-KiloBYTE/sec upload speeds per ip connection. It wouldn't be so bad if you only have 5 or fewer connections total at the time, like might be the case on dial-up...but with 40+ connections the keep-alive packets themselves end up crowding out data traffic. Plus, the packets themselves have a minimal overhead of about 32-64 bytes...so if they're only carrying a few bytes of real data due to low upload speeds per upload slot, they are like a 5 ton mail truck carrying 1 letter. Insanely inefficient.

Emule works by putting someone in queue for your files that isn't actually connected to you, so it can (somewhat) handle lots of people trying to download your files at once. Its queues don't reflect reality because the network often cannot keep track of who's still online or not in queues of 1000+ in length. Waiting a week to START a download is insanely inefficient, and kills dial-up's ability to participate in any reasonable fashion.

BitTorrent maintains connections to people on the same torrent as you even when no file transfer occurs between them, so it has to be very limited on the number of connections per torrent and global max or you'll find individual torrent upload speeds as bad or worse than dial-up speeds.

Low upload speeds PER upload slot on BitTorrent are almost worthless because of torrent piece sizes. With piece sizes typically 256 KB for even torrents less than 20 MB in size, and often 4 MB in size for torrents over 1 GB in size, ...uploading at 1 KiloBYTE/sec for the 256 KB piece size will take about 4 1/4 minutes. For 4 MB piece size, it will take about 70 minutes. At 100 bytes/sec upload speed...those numbers increase to 10+ times that. Until then, nobody else has anything to share. BitComet is notorious for such low upload speeds, and really sabotages otherwise well-seeded torrents because of it.

[Timwi]

eMule automatically selects a sensible number of upload slots without compromising the availability of all the other thousands of files that I'm sharing that don't happen to be uploading at the moment.

I notice that you are dead fixed on this upload speeds/upload slots idea and that you will never actually address my posting or my questions, so I give up. I have no idea what "scrape my boy, scrape" is supposed to mean. So I will continue to share thousands of files on eMule and only a few on BitTorrent, because (apparently) that's all your software allows me to do.

You are trying to compare a downloader-supplemented download accelleration system (bittorrent) to a peer to peer network (ed2k).

What an artificial distinction. Both descriptions are vague enough to apply equally well to both systems.

[The8472]

It's quite simple: The "availability" of a torrent as you call it is nothing more than the seed count reported on the tracker. You're saying that you don't want the upload to be thinned out, this means the upload has to stay with one torrent, this means you can't upload to other torrents. Sure, you could start them and announce to the tracker... but you couldn't upload to them. And then you shouldn't connect to peers either, since that would cause immense overhead to connect to peers of many torrents you're uploading to. This in turn means that the peers don't see you and their local availability-indicator wouldn't change.

Summa summarum: You'd just make the tracker statistics even more inaccurate than they are now.

If you want to maintain the availability of rare torrents just adjust your seeding order (don't know if µT can do that) to sort by the number of seeds.

Point in case: Many bittorrent-experts and/or knowledgeable power-users here have told you that what you want a) doesn't make sense or ill-explained, i suggest you listen.

[Saribro]

Stop treating BitTorrent as if it were eMule or WinMX or KaZaA or LimeWire or whatever the current flavour, because it simply isn't. The limitations in the client are a direct result of the protocol, get over it.