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". 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. 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. 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. -- 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 _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
