* Ed Tomlinson <[EMAIL PROTECTED]> [2007-05-21 12:45:21]: > On Monday 21 May 2007 06:25, Florent Daignière wrote: > > * Volodya <[EMAIL PROTECTED]> [2007-05-21 11:16:13]: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > [EMAIL PROTECTED] wrote: > > > > Hello, > > > > > > > > I proposed an advanced option on the peers (friends) page for high > > > > speed links. > > > > > > > > In the present code, if you increase the outgoing bandwith the peers > > > > inevitably end up in backed off mode as the ones who cannot deal with > > > > the higher throughput backoff the incoming connection. I dont know the > > > > method used for Backed Off values but some basic math tells me that > > > > mode nodes can only receive 10K/s for each connection. Let me explain. > > > > > > > > If you have one node on default setting of 15K/s outgoing bandwith and > > > > 60K/s incoming (4xoutgoing). If a user has 6 connections you have a > > > > max of 10K incoming for each connection. 10K/s is double the speed of > > > > a modem connection and hardly broadband speed. IMHO This severely > > > > limits the speed of freenet. > > > > > > > > What I would like to see is the ability to set individual bandwith on > > > > peers OR designate a peer as high speed which excludes it from the > > > > bandwith management on the normal peers. This would send a message to > > > > the other peer requesting a high speed link which would appear on > > > > their peer listing as request for high speed and the speed requested. > > > > If they agree then the link operates at the new speed sending data at > > > > the maximum speed specified until there is no more data to send. > > > > > > > > Regards > > > > > > > > Jarvil > > > > > > This will also help those of us who are running more than one node and > > > they are on the > > > same LAN. > > > > > > > I have tried to explain it on irc: it doesn't and won't help... and > > probably will f*ck up the load-balancing. > > > > Even if we have "faster than other" links, the node doesn't take that > > into account when it routes requests : the "fast link" isn't more likely > > to be used than any other one because of how routing works. We route to > > what we think to be the shortest path not the local-fastest one (to > > avoid missrouting) > > This is not strictly true. We try to use the best route. If it happens to be > backed off we skip it unless all nodes are backed off. If a link is faster > it should be backed off less... If the nodes have agreed on a faster link, > load balancing should be able to take it into account.
Backoff isn't triggered by bandwidth shortage directly : bandwidth shortage causes rejections and rejections cause backoff to be triggered. NextGen$
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
