Ed Tomlinson wrote:
On November 18, 2003 10:06 pm, Toad wrote:
On Tue, Nov 18, 2003 at 09:55:54PM -0500, Ed Tomlinson wrote:
On November 18, 2003 09:48 pm, Toad wrote:
On Tue, Nov 18, 2003 at 09:47:03PM -0500, Ed Tomlinson wrote:
On November 18, 2003 05:29 pm, Toad wrote:
On Tue, Nov 18, 2003 at 11:00:27PM +0100, Thomas Themel wrote:

( ^^ this is just plain silly, but it must be important!)


It doesn't matter. Slow data is better than no data. And NGRouting is
quite capable of routing around slow nodes. What is HARD is dealing
with QueryRejected's.

I will agree with this to some extent. However it _does_ matter when we
need 5 mins to send a 16K file and this is happening on lots of nodes. Is not this what happened when the switch was off, so its not the
solution either.

No. As I said, NGRouting will be able to fix it. Look at your
successTransferRate for the days when it was disabled.

Maybe (just maybe) the best way to handle the massive number of sends it to time them out if they do not achieve a high enough rate. ie. accept a low sendData number when the sends do not progress fast enough and we end up with a giant queue. Given

uh oh, talking about rates again! Toad has described 1 byte per minute as an attack. Is it reasonable to specify a minimal threshold , below which is "attack" or "unhelpful" territory, and above which is "acceptable" or "progress" territory ? I'm not suggesting either way, just asking about rate "control."

> that there are lots of DSL type connections out there, IMO we
> have to limit sends somewhere.

are we still steadfastly opposed to limiting the number of active
trailers between a pair of peers ? It is just another option, is
all. It is hard to represent, when they all have different start
and end times... but if the effective rate per trailer is WAY LOW,
could that be a criteria in deciding whether to add more trailers?

ken

_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to