* Thomas Bruderer <bruthoma at student.ethz.ch> [2006-04-19 09:31:55]:
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890 > > > The testenviroment right now is quite perfect, > > > > According to freeviz it's far away from beeing perfect ! > > http://freeviz.freenetproject.org/ what are we talking about ? the longest > > route atm is hardly 12 nodes long ! > > agreed, I meant ideally of "no congestion" "not many side effects" > Do you know what the default HTL is on .7 ? > > Idealy we agree, but because of the "now", I must disagree. > > under the circumstances we face the inserts should be fast, "now" > will be in the future. > > > Most of the time, with the current load detection algorithm, your insert > > request will be discarded/rejected on its way. The length of the path DOES > > matter on the rejection probability. > indeed and thats the problem, as I already said before. Its not the length of > the chain, its the probability of the rejection. Which shouldnt happen in > testnet, so THIS is no reason for insert slowness. May I ask you if you know why this probability of rejection exist ? Hint, they are several reasons... > > > > When you request data on the network, you target a location on the keyspace > > as well, but as soon as the data is found, you return it (there will be a > > DNF > > if you reach the HTL). It means that inserts won't EVER be as fast as > > popular > > content : requested content will be cached along the path and afterwards > > picked up from there. > > If you would read my posts, I recommend the starting post of this thread. I > already said that it doesnt depend on the length of the chain has no influence > on the bandwith we can use. And yes it has an influence because the algorithm > right now depends on the information we become back. > > > see ^-^ > Yes I see, but it wont be more true if you repeat it over and over again. > I'm just hopping you'll figure out yourself what the matter is. Hint : think in terms of security : Datastore probing, spamming, ... > > > We should check different strategies in testnet till inserts are fast at > > > least in testnet... > > > We agreed that by now black magic/alchemy time is over and we will try to > > understand WHY it doesn't work insteed of trying experimentaly to workaround > > problems. It doesn't mean there won't be a testnet with a modified code > > soon. > > yes and I am glad that this approach is such successfull as it is right now. > But we already know what the problem is. we need a guess of the bandwith we > can > use. I'm happy you know what the problem is. May I express my doubts? I'm not convinced that we should think in terms of "bandwith"... There are two different things : "bandwith" used in between nodes and overall insert speed; What are you talking about ? And I personnaly don't know what the problem is : I've got some rough ideas of what the problem might be, that's all. >The first approach was a TCP like idea, which is in principle ok, but its > meant for a 1 to 1 connection, and what we face is a 1 to many or 1 to network > connection... > > we cant ask the network, hey how much bandwith do you have for me for the > keyspace near X. But we would need exactly that info, if we want insert a > block > X. I want to be sure you dont believe the myth "inserts" have to be slower > than > "downloads". This is no fundamental fact in this universe. > We won't ever agree :) There are "fundamental reasons" : I'll just give you some pointers : fight against spamming, it takes more time to fec encode than to decode, you've to insert more blocks than what you need when you request the same key, ... rejection probabilities are higher on inserts as paths are longer and they are cumulative. I suggest you take a break and think about it :) The purpose of freenet isn't to be an efficient way to insert warez : inserts speed aren't going to be as fast as they could be on other p2p softwares. I don't think that having download and upload speeds as fast is either a project's goal or more generaly speaking technically feasible. There is currently a known problem : inserts are so slow that it doesn't give users a good experience. This problem is beeing addressed but atm we don't have any working solution, maybe you can help and suggest something insteed of whining about insert speeds ? What's your proposal ? getting rid of rejection probabilities ? You'll see it's nonsense if you've got the answer to the second question. > PS: ignored your flames... do it elsewhere... frost is a nice place for > flames... It wasn't meant to be flames, sorry if it gave you this feeling. I just think that the thread should be on @tech and not @devl :)
