On Wed, Apr 12, 2006 at 07:16:55AM +0000, Thomas Bruderer wrote: > > Why are inserts so slow? > > Well, inserts visit more nodes. This means: > > a) They take longer, (quite a lot longer) and > > a) They do, but I don't agree that we cant send more packets.
The algorithm we use uses RoundTripTime / windowSize as the inter-packet send time. It is explained on the wiki: http://wiki.freenetproject.org/LoadBalancing RoundTripTime is clearly SIGNIFICANTLY higher. > > > b) They are more likely to get a RejectedOverload (or a timeout). This means that windowSize is significantly lower, because windowSize is increased when we don't get a RejectedOverload, and decreased when we do. Therefore RTT/windowSize is going to be SIGNIFICANTLY larger, so we send far fewer inserts. > > b) agreed, but that is obviously not the Problem. If I can insert in an exact > Intervall of 15 seconds none of them seem to dropped anywhere. So each tried > insert does work, but they are much too far apart. We have to adjust the rate at which we send inserts according to the load on the network. The algorithm we have established is based on what TCP does and therefore should be solid. Unfortunately it makes inserts *really* slow. > > I'll probably checkout the insert-source tomorrow. (for a more technical > reaction) Right now I dont know exaclty how an insert work. 1 Phase (starting > sending Data immediatly to possible node) or 2 Phases (searching a chain, and > sending along the chain)? the Packets are much smaller now, I hope 1 Phase is > used. Especially since the Incoming packets are not the problem normally in > asynchrnous connections. Inserts are allowed to take a long time, so it doesn't make that much difference. As a matter of fact it's one phase. > > In My Case (one outgoing connection) I could and I should send as much data > as I > can as long as the other node doesn't complain about it. And the server doesnt > complain (he is quite idle), he is well connected to other nodes, so he can > send > at max speed aswell. A downstream node may complain because he is temporarily overloaded. The RejectedOverload will be forwarded back to me. Inserts visit far more nodes than requests so this is much more likely to happen on an insert than on a request. That is the problem here. > > This means as soon as a block is completly sent the next block must start the > next transfer (not necessary my insert, but data). If the node can't do that I > waste nearly 94% of my connection, and we all know that uploadbandwith limits > most of the users, and if freenet cant at least use the limited upload, an > insert will be still horrible. I give you a comparison: The problem is that the WHOLE NETWORK must have sufficient capacity to deal with the request, not just the few peers directly connected to your node. > > If I insert a VideoCD around 600 MB, with my uploadaspeed I can up it in > around > 6 hours, right now it would take 3.75 Days. Thats the kind of difference the > user WILL notice. > > The darknet is not very crowded at the moment, there are not many timeouts, > what > do you think if freenet 0.7 grows to the state of 0.5? the inserts wont get > faster in such an enviroment. Load balancing is hard, and I wouldn't expect inserts to be much faster than the *average* upload bandwidth. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060412/f6c87d93/attachment.pgp>
