Von: "Matthew Toseland" <toad at amphibian.dyndns.org>??? >But the other question is, can queueing ever be helpful? It can if it allows >us to route more accurately (which NLM clearly does), and/or to run enough >requests in parallel that the longer time taken for the request to reach its >destination is offset. Is this condition met?
Experience with the deployed NLM showed that even in the fully congested case it had success rates of 60% for HTL 18,17 and 16, compared to less than 40% for OLM. This means that the requests are sent over fewer hops on average, because find the content fewer hops away from the requester. A download of 1MiB which is sent over 2 hops needs 2 MiB in total network bandwidth. If it is sent over only 1.5 hops on average, then it needs only 1.5 MiB total network bandwidth. So essentially NLM can distribute 30% more content with the same network resources?. And these numbers are actual observations. The only reason why this did not result in increased performance is that the nodes used less than 50% of their allocated bandwidth? - which is a problem with the bandwidth scheduler and not with queueing. Best wishes, Arne ?: The relevant network resource is upload bandwidth. ?: Source: observations from me and two other freenet users. PS: How exactly the bandwidth limiter is fixed is an implementation detail. I think you are actually the only person who can judge how to do this most efficiently. ___________________________________________________________ Schon geh?rt? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1743 bytes Desc: S/MIME Cryptographic Signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110830/02b4e75f/attachment.bin>
