On Fri, Oct 31, 2003 at 04:52:42PM +0000, Richard Lamont wrote: > On Friday 31 October 2003 12:37, Ian Clarke wrote: > > > As the developers work hard to improve the core operation of Freenet, > > it can be easy to forget about the more superficial, but equally > > important aspects of Freenet, namely installation procedures, and > > usability for newbies. > > Until the core operation of Freenet is improved, and improved enormously, > everything else seems irrelevant. The core operation is a real sticking > point and I think we need to be single-minded about diagnosing the > breakage before even thinking about other stuff - especially as only one > developer is doing nearly all the work. > > My node shifts 1GB/day in, another 1GB/day out, and only a fifth of > that is 'payload'. (The DS grows by about 200 MB/day and is nowhere near > full enough to drop anything yet.) Most of that 200 MB - maybe 90% of it - > will be en route to other nodes. So I'm giving away 100 MB of bandwidth > for every 1 MB I use myself. Some of this apparent 'waste' is essential to > preserve anonymity at both ends, but much is not. > > Freenet seems to use bandwidth extremely inefficiently. It sprays far > too many messages in all directions, most of which achieve nothing, > leaving very little of a default 12 KB/sec upload allowance to move content. > > Following the recent improvements, pSuccessRatio seems to have moved from > around 2% to around 2.5% and stayed there. > > Compared to this, other issues are nowhere near "equally important".
Unfortunately psuccess doesn't seem to actually mean anything. And it won't, at least not until we get the stats sorted out - probably by implementing the SFT... > > The objective is to get keys from a node that has them to the node that > wants them. Freenet needs designing to maximise the speed of delivery of keys. > > If messages take up none of the bandwidth, then no requests could be made, > and no keys would get delivered. > > If messages take up all of the bandwidth, then there would be no bandwidth left > for keys, and no keys would get delivered. > > Somewhere between these two extremes, there must be an optimum split of > bandwidth between keys and messsages that maximises the rate at which > keys are delivered. What would you suggest? Giving trailers a higher priority will only drive up messageSendTimeRequest and make the node useless. Is it a routing problem? Is it that 95% of requests are for data that simply isn't on the network? In which case, we need to look at enlarging the failure table - 1000 keys is simply too small for current usage IMNSHO. > > The ideal rate of sending messages would be the rate which is just enough > to keep keys flowing fast enough to fill the pipe. Any more is worse than > useless, because it will just waste bandwidth. Why is "wasting bandwidth" such a big deal? > > Have the developers given this any thought? All I've seen are one or two > hints in various places that messages must have priority over payload. If > developers are working on the basis of this belief, then that is the root > of the performance problem. I repeat my question. There are lots of packets mainly because routing doesn't usually find the node we want the first time, and because a lot of queries fail, many of which are for data that wasn't there in the first place. Messages must have priority over trailers in order to be delivered in reasonable time - or that's the current understanding anyway. QueryRejected messages and so on have a lower priority though. But the basic misunderstanding here: we create messages for a reason, we don't just pluck them out of thin air... > > > -- > > Richard Lamont > <[EMAIL PROTECTED]> > OpenPGP Key ID: 5ABEC9C3 http://www.stonix.demon.co.uk/key.txt > Fingerprint: 9DEE 7113 DF02 A516 404C 22AC 1FF6 185D 5ABE C9C3 -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
