Query efficiency
 

Howdy.

A 3.8.6 Pro under win32 running as a leaf node on a DSL connection. I was suprised to notice the box was receiving an average of 13K/second in query requests alone. Is this much overhead normal ?


Digging deeper into the advanced stats:

Average query messages/s: 129
Average duplicates/s: 70
Average false positives/s: 37

There also seemed to be a handful of query too large and illegal character in query errors happening per hour. During the 2-hour period these stats were recorded stable connections to 6 LimeWire 3.8.6 ultrapeers were held.

The gross figures seem to match up with those reported at the router, I believe they are reasonably accurate.

Re: Query efficiency
 

No, it's not. You're either sharing a hell of a lot of files or something is seriously broken. The average ultrapeer only handles about 30 queries per second - that means the ultrapeers connected to you must have forwarded most of the queries they received.

Re: Re: Query efficiency
 

Sharing quite a few files, yup. Anything to be done to reduce the overhead ? Connect to fewer UPs perhaps ? If I understand matters, the large number of duplicate queries would indicate that this wouldn't reduce the gnode's horizon to much.

All suggestions welcome.

If you know how to configure this setting, yes.

That's right.

I think to receive that much of queries you have a QRP table full. The only thing to reduce the overhead is to share less files... (maybe the ones you think are more worthwhile ou are rare for the Gnet). With a QRP table full the ultrapeers send ALL the queries they broadcast to you.

Ciao

Thanks for the replies guys.

Et voilà - any indication of how large a QRP table might normally be please ? Ta.

The only method I think of is by having two machines with LW on them, one starts as a UP and you manually connect the other machine to it. In connections you enable the QRP traffic (%) column of the machine acting as UP. Sorry I don't know how to do it easier. But with the QRP system, sharing more than 1000 files is overkill and creates much false positives (lot of unessary traffic) especially with generic terms that are popular in searches.

à+

Ah .. many more files than a thousand.

I'll switch the box from being a leaf to an ultrapeer to avoid generating unnecessary traffic for other UPs and see about reducing the size of the shared fileset.

Cheers.

I think LW developpers should make it possible for a leaf to send multiple QRP table that have a maximum filled pourcentage of 15% or make the QRP tables of 256KB like bearshare instead of the 64kb used actually. I prefer the first solution as it is more scalable and efficient. Is Trap_Jaw volunteer to write that code? ;)

Ciao

I think there's a better solution to the problem. LimeWire is currently not sending any queryreplies when all its upload slots are filled. A leaf that is sharing all those files will be busy most of the time and it won't return any queryhits. So the leaf could simply send a message to the ultrapeer, telling it to stop sending queries.

I prefer that over increasing the size of the QRT because transmitting a larger QRT means more traffic for everyone - and the savings for people sharing lots of files wouldn't be nearly as large.