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" > 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. > > 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. > > 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. 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. PS: ignored your flames... do it elsewhere... frost is a nice place for flames...
