On Fri, Oct 31, 2003 at 08:23:06PM +0000, Richard Lamont wrote: > On Friday 31 October 2003 19:03, Toad wrote: > > On Fri, Oct 31, 2003 at 04:52:42PM +0000, Richard Lamont wrote: > > > > Following the recent improvements, pSuccessRatio seems to have > > > moved from around 2% to around 2.5% and stayed there. > > > > 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... > > Well, if the stats are telling porkies, diagnosing the problem is even > more difficult.
Yeah. :( > > > > 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 usefulness of a node is a function of its ability to deliver keys. > > All I'm suggesting is that if the bandwidth is allocated 80:20 keys:messages > then Freenet will be four times as fast than if the ratio is the other > way round (as it appears to be at present). Well if you have any practicable ideas of how to achieve this, now's the time for them. > > As for which messages are dropped or delayed, I couldn't comment. I don't > know enough about it, and AFAIK FNP isn't documented so it's more or less > impossible to learn how it works. All I'm saying is that if 80% of the > bandwidth is spent shifting keys, then Freenet will go four times as fast > as at present. There is a spec in CVS somewhere... > > > > 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? > > I can't believe you are asking this question. > > Most Freenet users are on cable modem or ADSL connections, with typically > a 128 or 256 kbit/sec uplink. The default config bwlimits to 12000 Bytes/sec. > If 80% of that is spent on message overhead, then payload can only move > out of a node at a paltry 2400 bytes/sec. And even that is shared between > all the TXing connections. > > Bandwidth is the most precious and scarce resource that Freenet uses. > Everything else - e.g. CPU and disk - is plentiful and cheap by comparison. > So to optimise Freenet's performance, it is essential to use Bandwidth > economically. Surely I can't be the first one to point out something > as basic and obvious as this? > > > > 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... > > Please step back from all this detail and look at the big picture. > > You create messages for a reason: to obtain keys. Keys can only flow > at a certain rate, limited by bandwidth. There's no point in sending > any more messages than just enough to get those keys sent, because they > cannot achieve anything. Yes, but we have to FIND the keys in order to transfer them. They do not come out of thin air. > > As for which messages to throw away, I don't know enough about FNP's > innards to offer any useful suggestion, and I'm more than happy > to leave that to you. > > I'm reminded of an old cartoon I saw years ago. It showed a huge open plan > office with hundreds of men in suits sat at desks punching calculators. > At the back the back of the room, there were two men watching this scene. > One of them, the boss, says to the other, "Do you know, Jenkins, no matter > how many accountants I employ, I can't seem to find out where all the > money is going." > > Freenet is a bit like that. It spends too much of the firm's money on > accountants. > > > -- > > 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
