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: > > > > > > Hi, > > > > > > > > > > > > my node is currently running off an ISDN link, and it seems to > > > > > > build up pretty high values in the connection manager's 'Data > > > > > > waiting to be transfered' counter. It's constantly around 30MiB, > > > > > > and that's more than the link can do in an hour under optimal > > > > > > conditions - I don't believe this makes sense. Or does it? > > > > > > > > > > > > Is there any way to get more sensible numbers? > > > > > > > > > > > > I've tried opening a lot of freesites, and they always seem to > > > > > > restart. However, some give me the "The request couldn't even > > > > > > make it off of your node." message, on a node that wasn't > > > > > > reseeded for months. > > > > > > > > > > > > Is this related? > > > > > > > > > > > > I get the feeling that the behaviour has worsened in recent > > > > > > versions, it used to work nicely around 632x. > > > > > > > > > > I suspect this is because we reinstated the QR based on bandwidth > > > > > code. > > > > > > > > Without the QR based on bandwidth code I had about 200MB queued in > > > > the OCM on 100-200 connections - all going thru a 10K pipe... It > > > > will take it a long long long time to send all that data. > > > > > > 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.
4K-6K per second... With a sendData value of bwtween .13-.29 So its still not doing that well. Mind you, you did fix a bug that might just help this... 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 that there are lots of DSL type connections out there, IMO we have to limit sends somewhere. Ed _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
