As mentioned before, I am sharing a fairly large number of 'small' files...
(I am also sharing some 'largish' files - 16MB-99MB - but no more than about 15 in that size range. Then about 90 files in the 2MB-15MB range.)
The balance of my approximately total 1,600 shared files are about 15% > 1MB... In other words, the great majority of my shared files are less than 1MB.

I am allowing 5 Upload Slots and a Max of 4 for Queueing. (The Max of 4 for Queueing is not constant - I frequently alter the setting in order to observe the impact on 'output' over a 3-4 day period... 'Jury' is still out !)
I use such 'small number settings' because they result in far higher overall performance. The one factor of p2p file sharing which is not to be ignored is that of 'exposure'... That means that the longer it takes to complete a file transfer the more likely it is that there will be some problem. In and Out as FAST as possible is the big key to success. Only way to achieve that with a given bandwidth is to do as little as possible as well as possible ! Hmmm ? Big 'pretty numbers' are a fallacy.

I mention all of the above in order to explain why it is that I am able to observe 'client performance' in a way that is not particularly 'normal' as far as the majority of people are concerned. I have an enormous 'turnover' per 24 hours with a very wide variety of clients Downloading from me.

With the proviso that there are always exceptions, in the comments I am about to make 'exceptions' mean 'rare occurences'. I am also going to refrain from mentioning ALL of the clients I observe.

In terms of 'speed' and successful 'completions' of file transfers there is little to choose between LimeWire, BearShare, Gtk-Gnutella, the LimeWire 'derivatives' and Gnucleus.
They are all fairly high-performers with rarely any problems.
The latest BearShare 4.4.0.5x series may have a slight 'edge' over the others... For now ! Mañana ??? Who knows ?

The variations in performance which I can observe are almost always due to 'operators' trying to do too much with too little. (I say that because, with enough years of experience with this loony hobby, it's not too difficult to 'read' what is going on at the 'other end'.)


The only client which is very frequently a problem, in regards to 'speed' - or, occupying an Upload Slot for hours for a tiny file; failure to 'close' on completion; 'retry/wait states' on the order of 10-30 times more than other clients - is Shareaza. (Ditto for Downloads from Shareaza Users.)


Specifically, and on topic here, LimeWire functions well for the very great majority of users.

Shifting 850MB to 1.05GB Uploads per day of 263kB, 684kB, 1382kB, etc., etc. files makes it fairly easy to clearly see what's doing what !

Although I am not using LimeWire now, it is easy to state that


LimeWire works.

If there are 'settings' problems associated with LimeWire, than that is another issue.
But it is an 'issue' which applies to nearly all clients.

__________________
Fusion for REAL!--CDex 1.51--Wackyuses--Bitzi - Check Files Before Download !--.mp3 File Name Change Problems? Try Rename-It!--Alternate PORTS--Avast- Anti-Virus--WindowWasher--IrfanView--PC Pitstop - Test your PC !--Mac OSX Troubleshooting--GO .ape ! - For 'Lossless' Audio Compression--Port :6346 - Test If It Is 'Blocked'--Cole2k Codecs--OldVersion - Newer isn't always better !
Nod32 - Free Virus Scan: Use ESET's Online Antivirus Scanner

Tomorrow's forecast:
Sunni in places, Shi'ite in others...