Utorrent Vs. Azureus in Superseeding mode.

[kokoko3k]

Hi all

I don't know if it is a known issue, nor if it is directly related to utorrent,

but Here's the scenario, i'll try to be as clear as possible.

-Private Tracker.

-First seed (A) using azureus 2306 in superseeding mode

-First seed (A) upload bandwidth is 10mbps

-First seed (A) free upload bandwidth is about 1mbps

-only two leeches connected to that torrent ( ©

-one leech ( uses azureus 2306 with free upload bandwidth of about 2KBps

-the other leech (C, me) uses utorrent Version 1.4.1-beta (build 406) with free upload bandwidth of about 2Mbps

-A starts seeding

-C is the first leech connected to the torrent

-C downloads at about 1mbps

-5 minutes later the other leech B using azureus connects too.

-A switchs to superseeding mode

Here's the problem:

A seeds B at almost full bandwidth

C gets very little bandwidth from A and B.

As soon as B is 100%, A switches to normal seed mode

A seeds C at almost full bandwidth.

Isn't strange that azureus superseed gives all of it's upload bandwidth to another azureus leech regardless of it's very poor free upload bandwidth ?

Thank you very much.

[DreadWingKnight]

You're comparing apples and oranges for superseed algorithms here.

Azureus superseed is a 1-n upload order

µTorrent superseed is a forced rarest-first upload order

They are completely different algorithms

[Kazuaki Shimazaki]

Speak in human language, DreadWingKnight!

The implementation and mechanics might be different, but the goal will still be to produce a new seed ASAP, no? If so shouldn't both implementations make a seed out of the guy with the higher bandwidth?

[kokoko3k]

You're comparing apples and oranges for superseed algorithms here.

No, you didn't understood what i was speaking about.

but it's quite simple, try to read my post again, because i never spoke about utorrent superseeding.

i've said that azureus in superseeding mode preferred to upload to another azureus leech, even if the other one (leech, utorrent) had a higher (much higher) upload speed.

[DreadWingKnight]

The implementation and mechanics might be different, but the goal will still be to produce a new seed ASAP, no?

No, the goal of µTorrent's super-seed is to increase the occurance of rare pieces in a swarm

Azureus uploads each piece once, in order, then loops until new seeds spawn.

If the piece distribution suddenly drops in the azureus method, old pieces that aren't present anymore won't get re-uploaded until the entire torrent has been uploaded once.

I have seen Azureus super-seed mode take up to 200% of the torrent's total size to generate a new seed.

BitTornado's super-seed takes approximately 105%-110% of the torrent's total size.

If so shouldn't both implementations make a seed out of the guy with the higher bandwidth?

Only if that guy is seeding to everyone else at an equally high rate. µTorrent's super-seed is more based on BitTornado's super-seed mode (Reference documentation) and will go back to previously uploaded pieces if they disappear from the swarm. Additionally, the BitTornado core super-seed has mechanisms to adjust piece availability in the case of people resuming from other sources (such as a batch torrent where people have varying levels of complete already).

Trying to compare Azureus and µTorrent super-seed mode isn't possible because of the immense differences in the goals.

[DreadWingKnight]

i've said that azureus in superseeding mode preferred to upload to another azureus leech, even if the other one (leech, utorrent) had a higher (much higher) upload speed.

Peer preferencing by client version.

Not good behavior.

[kokoko3k]

Yeah, that's the point.

Is that a known issue ?

[DreadWingKnight]

I'm not sure, but it needs to be reported to the azureus devs, since there's nothing the uTorrent devs can do about an azureus-side issue.

[kokoko3k]

Yeah yeah, you're absolutely right, i'll do.

But i said something similar about bitcomet, and firon was so kind and he explained me very well XD.

[Firon]

Well, unlike BitComet, Azureus is actually developed, so it might be a good idea to point it out to them (perhaps with repeated tests to confirm it wasn't a fluke?)

[chaosblade]

I doubt the azureus devs put some kinda of internal preference like that, but it will probably do good to report it anyway.

[kokoko3k]

I've made several tries.

Now i tried azureus in superseeding mode with utorrent,azureus and the official client as leeches.

It seems that the only client which didn't recieve anithing from azureus (the seed) is utorrent.

Could you developers do something ?

thanks.

[kokoko3k]

i don't want to bore you, maybe this could be useful:

Now i'm using Azureus in SS mode, i've a leecher who is using utorrent and my upload is slow and stops frequently.

Looking at the azureus console in logging mode, it seemds that the clients speaks only about one or two parts, after that utorrent says BT_UNINTERESTED and azu sends the choke, ending transmission:

--

[3:11:41.171] {net} Received [bT_UNINTERESTED] message

[3:11:42.125] {net} Sent [bT_CHOKE] message

[3:12:17.562] {net} Received [bT_HAVE piece #33] message

[3:12:20.765] {net} Sent [bT_HAVE piece #35] message

[3:12:21.343] {net} Received [bT_INTERESTED] message

[3:12:23.125] {net} Sent [bT_UNCHOKE] message

[3:12:23.562] {net} Received [bT_REQUEST piece #35:0->16383] message

[3:12:23.562] {net} Received [bT_REQUEST piece #35:16384->32767] message

[3:12:23.640] {net} Sent [bT_PIECE data for piece #35:0->16383] message

[3:12:23.640] {net} Sent [bT_PIECE data for piece #35:16384->32767] message

[cut]

[3:12:40.171] {net} Sent [bT_PIECE data for piece #35:507904->524287] message

[3:12:41.281] {net} Received [bT_UNINTERESTED] message

[3:12:42.125] {net} Sent [bT_CHOKE] message

--

[mighty]

"I doubt the azureus devs put some kinda of internal preference like that, but it will probably do good to report it anyway."

i agree!

[Zoz]

Greets,

I stopped by this forum specifically due to the OPs experience - and I stand behind his observations.

I run Azureus, and have noticed this behavior when I superseeded with 2.3.0.6, and every version through current 2.4.0.1.b13 beta.

I don't believe most who have read the thread understand the complaint. This behavior is only noticed with Azureus superseeding to a uTorrent client.

What I see is I superseed to ANY other client at full bandwidth. When seeding to uTorrent, there is about a 1 minute delay after each piece sent. During this 1 minute, uTorrent has the INTERESTED flag turned off - so naturally, Azureus does not send the next piece.

As soon as uTorrent turns the INTERESTED flag back on, I'm blasting at full bandwidth to him.

The cycle then repeats. If it takes 30 seconds to xfer a piece, this results in a 66% idle time - net effect is uTorrent experiences reduced bandwidth when Azureus is superseeding.

I don't think this is a problem that simply can be ignored by pointing a finger at the Azureus devs... something is going on here with the uTorrent turning off its INTERESTED flag after every superseeded piece.

[Zoz]

I did some more research and found that uTorrent seems to be waiting an awful long time sending the BT_HAVE piece message:

This is an Azureus log to a uTorrent client:

[10:32:02.666] {net} Received [bT_REQUEST piece #986:2080768->2097151] message;

[10:32:03.525] {net} Sent [bT_PIECE data for piece #986:2031616->2047999] message;

[10:32:04.541] {net} Sent [bT_PIECE data for piece #986:2048000->2064383] message;

[10:32:06.213] {net} Sent [bT_PIECE data for piece #986:2064384->2080767] message;

[10:32:07.431] {net} Sent [bT_PIECE data for piece #986:2080768->2097151] message;

[10:32:09.900] {net} Received [bT_UNINTERESTED] message;

[10:32:17.010] {net} Sent [bT_CHOKE] message;

[10:32:54.135] {net} Received [bT_HAVE piece #986] message;

[10:32:57.635] {net} Sent [bT_HAVE piece #993] message;

[10:32:58.978] {net} Received [bT_INTERESTED] message;

[10:32:59.994] {net} Sent [bT_UNCHOKE] message;

[10:33:00.244] {net} Received [bT_REQUEST piece #993:0->16383] message;

That's over 45 seconds! Other clients send the BT_HAVE within 1 second. This example file is 4GB. Is the piece and file so large that uTorrent handles the save poorly and takes 45 seconds to save it?? I haven't experimented with a smaller file and uTorrent.

Based on this, I s'pose the thread topic should be "Why does uTorrent take 45 secs to ack a received piece from a super-seeding Azureus client?"

[The Mighty Buzzard]

The BT_HAVE message shouldn't have anything to do with it. Seeds, super or otherwise, needing to recieve BT_HAVEs at all is specifically out of spec for the protocol. That being said, the BT_UNINTERESTED message looks to be the problem, not the BT_HAVE.

[Zoz]

Standard or not, every other client I've looked at is doing this during super-seeding:

[3:15:15.666] {net} Sent [bT_PIECE data for piece #1006:2080768->2097151] message;

[3:15:16.978] {net} Received [bT_UNINTERESTED] message;

[3:15:16.978] {net} Received [bT_HAVE piece #1006] message;

[3:15:17.088] {net} Sent [bT_HAVE piece #1013] message;

[3:15:17.603] {net} Received [bT_INTERESTED] message;

[3:15:18.369] {net} Received [bT_REQUEST piece #1013:0->16383] message;

In this example, essentially zero time passes between packets vs. uTorrent's 45 seconds.

[The Mighty Buzzard]

Then Az is going contrary to protocol, pure and simple. Not that I have anything in particular against BT_HAVE getting sent to seeds, but if it's not required in the protocol they shouldn't write code that requires it. This is Az's bad, not µTorrent's.

[Zoz]

From the thread in FOUND BUGS:

Like the sticky says, any report that's not done with the latest beta build is ignored.

More than half the time, what people mention has already been fixed. This is one of them.

Grab the beta, gents, or live with poor exchange rates when transferring from super-seeders.

Zoz out...