Re: [freenet-support] towards Freenet 0.7.0

Top Page
Author: Matthew Toseland
Date:  
To: support
Subject: Re: [freenet-support] towards Freenet 0.7.0
Delete this message
Reply to this message
gpg: Signature made Thu May 1 22:32:19 2008 UTC using DSA key ID E43DA450
gpg: Good signature from "Matthew John Toseland <toad@amphibian.dyndns.org>"
On Thursday 01 May 2008 16:20, sich wrote:
> Ermanno Baschiera a écrit :
> > Hi,
> > In my opinion a good bandwidth control system should be necessary. I
> > read that at the moment it's not very accurate. I think that all
> > people with low bandwidth can benefit from an accurate bandwidth
> > control. I mean... think about new comers who want to give a try
> > running Freenet... They keep the node up for some days... their MSN
> > starts to disconnect every 5 minutes, surfing becomes slow and they
> > often have to reload pages... even if they set their node's output
> > bandwidth to a resonable value. I'm afraid they at last could give up
> > and unistall freenet.
> > I had those problems, but with the last 3-4 builds, it happens much
> > less often, and I can't exclude that it could be my isp's fault (maybe
> > throttling?) or something else, not Freenet. Anyway, an accurate
> > bandwidth control cannot hurt.
> >
> > -Ermanno Baschiera
> For me the problem is that Freenet don't use all the bandwitch
> avaible... I have very good bandwitch but Freenet is only using around
> 40ko/s...


Do you have 0% pInstantReject as well? If so, your node is accepting every
request sent to it, yet is still not using much bandwidth (compared to what
it could do). Which is what I find on my node when I run with a high bwlimit:
our neighbours simply don't send us enough requests to use up all the
bandwidth, even taking into account that their neighbours are probably
rejecting a lot of requests, so we probably get a lot of the rejected
requests due to not being backed off.

I don't know that there's much that can be done about this. Load limiting
adapts to the average network conditions, and we can't go too much beyond
that without breaking routing.
>
> sich