Toad <[EMAIL PROTECTED]> writes:

> On Tue, May 25, 2004 at 05:04:53AM +0000, Wayne McDougall wrote:

> Not terribly well, because of high level bandwidth limiting. The node
> needs to know how much bandwidth is available to estimate how much is
> being used and therefore how many queries to allow.

With respect this seems insufficiently good enough for the real world
nature in which a node will run. People will want (I want) Freenet to
notice that its share of bandwidth has been dropped and to react accordingly.

Current messageSendTimeRequest seems a good measure of that.

So I naively ask can't we mroe dynamically adjust bandwidth caps down when we
see messageSendTimeRequest shoot up? Probably not...I suspect that would create
a vicious circle. Ok but isn';t there some measure Freenet can use to notice
it's getting choked and not to try and hog the connection?

Ok I am for all intents and purposes and innocent newbie whose just been
quitely running a node for two years, trying to share what bandwidth I can
because I think the project is worthwhile and bandwidth (so I've read)
is the greatest need. 

And certainly I've seen Freenet (when on a good enough build, which is usually
the case) sucks up every last byte of my bandwidth and I like to think that
that is being useful to someone somehow. I've assumed that if my 80 Gb
datastore fills up at 1 Gb per day, and Freenet still routes to and through
my meager 128/128 kbps line (even when I cap it lower) that, hey, maybe my 
node is useful or needed or something.

And when I see something new on COFE and follow the link and find 10% of the
data is already in my meagre 1.5 Gb store I think hey, it got there somehow.
I'm impressed with how well it works. Much better lately, thank you Toad.
And I'm amazed so many connections are to Sweden or Germany or such like. In
fact I've ever only noticed one (brief) connection to a New Zealand node. 
I'm not sure what that all means, except that even on a (by world standards)
a relatively low bandwidth node, Freenet is highly functional to me.

I'm point is that I read and try to understand but I'm a 
newbie and may blather in my innocence...forgive my questions....and
comments. I don't expect agreement. But I throw them out anyway.

> > I watch (with envy) discussions on bandwidth and pricing and (sadly) I
> > think the world is moving more to caps (monthly limits) rather than open.
> It certainly is in Oz and NZ.

Indeed. And I notice the whining of people in the US when their providers move
them on to similar capped plans. Maybe the competition is strong enough to
mitigate that, but bandwidth ain't cheap and simple economics seems the way
to stop the leeches. I see it as a growing trend. But that's just my view.
Wish it would trend the other way.

> There is sadly no priority in it ATM. To help one user run a node in a
> wierd situation... hmm. I'll think about it.

Absolutely. You set the priorities. I have no expectations that anything 
would be done about it. Mostly I have a questions, which I think is still

How will a node respond if one set of connections has a high bandwidth cap
and another set of connections has a low bandwidth cap (assuming these caps
are applied externally). Does the node give its average recommendation on
retry intervals and load to ALL the connections? Will the high bandwidth
connections figure out this is a good node to deal with, even if I'm sending
out a retry interval based on averages.

Put another way: does freenet assume all my outgoing and incoming connections
have equal bandwidth throughput? Does that affect routing in a suboptimal

Depending on your answers I may have other questions such as "should I run
two nodes - one for high bandwidth only and one for low bandwidth? Blocking
connections from the wrong connection set? Or just what should I think of
doing in these cases?"

Finally I'll just politely take issue with "one user" in a "weird situation".
I don't think the situation is as weird as you might think. And it ain't 
just one user. I appreciate that it still won't be enough to be a priority.
I didn't expect that. But it may be as you work on infrastructure and future
changes you may give a little thought to how a few small changes in plans may
make it better for us in a "weird situation".

Support mailing list
Unsubscribe at

Reply via email to