Azureus + 7-STABLE == Slow download + No Upload
lists at thefrog.net
Thu Jul 31 09:20:04 UTC 2008
On Apr 3, 2:24 am, scra... at hub.org ("Marc G. Fournier") wrote:
> > > The reason that we've persisted with doing patchsets for Java is so
> > > everybody can get at the source and investigate/fix things which are
> > > important to them. I've persistently argued against switching solely
> > > binary releases, when that has come up, for just this reason.
> > First, a note ... I think the Java group is doing a fantastic job,
> > considering all of the hurdle that you guys had to jump through at the
> > start of this with NDA (I believe?) and such ... please do not take *any*
> > of what I have (or will) say as anything but an attempt to further
> > improve, as they aren't meant as anything but ...
> > > So, if you can't find someone on the porting team who is both
> > > and has time to investigate it right now then there are a number of
> > > you can do yourrselves to start the investigation.
> > In this case, I'm curious as to why nobody is taking this as an
> > opportunity ...Azureusis a huge piece of software, that tends to make
> > extensive use of threading (from what I can tell), and since at least
> > has had problem reports when trying to do 'two things at once' ... if
> > is a coding bug withAzureusitself, fine, but if this is a bug with
> > FreeBSD (ie. our threading + java) thatAzureushighlights to the extreme,
> > then if we can getAzureusfixed, that would trickle down to other less
> > 'intense' java applications, and, possible even non-java ones ...
> > *But* ... after installing deluge (python), which I'm getting massive
> > transfer rates (such that I'd never seen withAzureuseven at its best)
> > even with 20+ torrents on the go, I don't see it as being a FreeBSD
> > threading issue, except for how that interacts with Java+Azureus...
> > Now, it could be like with Wine, whereAzureuswas programmed with 'linux
> > in mind', so that someone is missing / broken in FreeBSD/java in relation
> > ... but even knowing *that* would at least make it easier for ppl posting
> > about such issues ...
> > > . Look through the list archives into what people have found out about
> > > problems withAzureusbefore. This isn't the first time this has come
> > > up.
> > I've done that, and you are right, it isn't the firs time ... the bulk of
> > the reports have revolved around 6.x, where you need to add an entry to
> > /etc/libmap.conf to map pthread -> thr ... with that,Azureuson 6.x works
> > fine, but with 7.x, thr is the default library, and I've checked jdk15
> > using ldd to make sure that that is what is being used ...
> > The only other issue I've found relates to IPv6, but I don't have that
> > built into my kernel, and, just in case, I did add the flag that was
> > suggested to force IPv4 ...
> > The other email's that I've seen on the subject generally went along the
> > lines of "I gave up onAzureus+Java and moved to something else to fix the
> > problem" ...
> > > . Look at what the kernel threads are doing periodically with ps(1).
> > What should one be looking at here? I have no problems with doing the
> > 'leg work' on this, just need to know what I need to be looking for ...
> > > . Dump the Java threads periodically.
> > Huh?
> > > . RunAzureusunder ktrace and look at what syscalls are being made.
> > > There is going to be a lot of output from ktrace I expect, so its
> > > going to take some time to sort through.
> > I have the disk space, but insufficicent knowledge to know what I'm
> > looking for from the output ...
> > > . Run this on 6.x and 7.x and try the different threading libraries.
> > 6.x runs fine with the pthread->thr map in /etc/libmap.conf ... I've
> > it on 7.x with both diablo (uses pthreads, I believe) and jdk15 (with
> > .. same results ...
> > > . Run it on Linux and compare what it does if you're interested.
> > Not an option ... I don't have a Linux box to run it on ...
> > > . Run it under different JDKs to see if that makes any difference.
> > Tried both diablo and jdk15 ... haven't tried the linux jdk though, will
> > look at installing that tonight ...
This thread's gone a bit quiet, so I don't know if there's a solution I've
missed (or more likely everyone's given up on Azureus for deluge), but I
just tried azureus again to see if it'd been fixed in the last couple of
months and I saw the same problems - plenty of users to connect to, plenty
of fully established connections, but very few peers/seeds were able to
send/receive data - I noticed that it wasn't that only Azureus users could
send, but a very select few of the Azureus users...
After enabling a few extra columns in the peers display (most notably the
'Encryption' column) I saw that it was only the users with 'RC4-160 (UDP)'
in the encryption column that were getting data through. It's not just
encryption alone, because those with just 'RC4-160' weren't sending any
data, it seems to be specifically those with the 'UDP' suffix, which I'm
assuming means they're connected over UDP rather than TCP.
I know people have been talking about threading as a likely culprit, but
perhaps its something to with TCP connections (or threading of TCP
connections specifically?) Unfortunately I'm not really sure how to go about
testing/confirming/fixing this, but hopefully this info is useful for
someone who's better equipped to find the problem...
On a side note, it seems that the Azureus/Vuze devs have decided to add in
an option to prefer UDP connections which might make this easier to test my
theory in the near future (see
More information about the freebsd-java