On Mon, May 24, 2004 at 09:05:42AM +0000, Wayne McDougall wrote:
> Phillip Hutchings <[EMAIL PROTECTED]> writes:
> > What would be nice (in lieu of being able to prefer certain IP ranges - I
> > get local traffic far cheaper) would be a way to limit monthly transfer,
> > eg set it so the node can use 5GB/month, and it'll aim for a daily
> > transfer of about 170MB, but will go over if it needs to. I guess this
> > would also mean that the size of incoming files would need to be limited.
> > 
> > Unfortunately I can't try to hack this myself just yet, but I have some
> > free time coming up, so I might look at it then, see if I can find where
> > to do the limiting. I knew Java knowledge would come in handy :P
> > 
> > So for now my node is offline. I've lowered my rate limiting to 500
> > bytes/sec to keep things under control, but I'm waiting for my ISPs
> > traffic information to come back online...
> Toad: feel free to comment on point 3:
> Phillip, since we're in the same country with similar issues, I'd like to share
> my thoughts and see where we can go with this. Feel free to email me directly.
> 1. My experience is that I can get a limit of 5 Gb of *international* traffic a
> month (170 Mb a day) with Node bandwidth limits of 
> Overall 0
> Output 750
> Input 0
> Yup, a limit of 750 bytes per second. I need to experiment more with the 
> Overall setting. Freenet is the single most effective utility I have found 
> for consuming bandwidth. Better than BitTorrent.
> When the bandwidth level drops this low I get a lot of what I characterise as
> "churn". The messageSendTimeRequest shoots up - I guess because messages can't
> get out fast enough through the small output channel. So then my node rejects
> incoming connections, but it's still sending outgoing requests (albeit slowly)
> so I'm rejecting these replies to my requests because my messageSendTimeRequest
> is so high. I suspect a lot of things get retried. I suspect my efficiency is
> low. But it works, and keeps me in the bandwidth cap. 
> 2. I really suspect that more serious bandwidth limiting should be done at an
> operating system (router) level rather than at the Freenet level. I suspect
> that's what you'll be told around here. That way you can also take account of
> things happening other than your node. :-) 

Perhaps. That would also lead to high message send times though. Freenet
needs to know what the limit is even if you use external limiting.
> So I've been working towards a Linux traffic shaper that gives sets no limits 
> on traffic with domestic IP addresses and limits international traffic so the
> total monthly limit hits 5 Gb (my cap).

HOW do you determine what is local? Freenet could maybe support this.
> 3. What I don't know is how my Freenet node will respond when some (domestic)
> IPs get a high bandwidth (8,000 k/s) and other (international) IPs get a low
> bandwidth (0.75 k/s). I guess  my node will always give a constant
> recommendation for how much traffic it wants, and this will oscillate wildly
> according to how many domestic versus international nodes are connecting. I'm
> *hoping* domestic nodes will learn that it is worthwhile connecting to me, but
> they may be put off by the average they get. I don't know. Someday when Toad is
> bored maybe he could put his fine mind to at least thinking about the impacts
> of this bandwidth disparity and how a node configuration could be set to handle
> this. 
> It may be that this scenario ( maix of low and high bandwidth channels into a
> node) is relatively uncommon worldwide, and isn't worth coding for, but I
> wonder how common it is, and whether it may become more common.

Are you in Spain by any chance? The last poster on this topic was..
> Comments welcome.
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

Attachment: signature.asc
Description: Digital signature

Support mailing list
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support

Reply via email to