[freenet-dev] Why Freenet is so SLOW! Proposal for new load management

[Robert Hailey]

On Nov 29, 2007, at 7:26 PM, Matthew Toseland wrote:

> I conclude that the reason that Freenet's performance sucks is that  
> the
> current load management algorithms do not adequately match demand to  
> supply!


On Nov 17, 2007, at 2:05 PM, Matthew Toseland wrote:
> The pubkey itself for an SSK cannot be encrypted as a node  
> forwarding an SSK
> has to be able to verify the signature.

Of course, there are two issues involved here... Slow (latency) and  
Slow (throughput).

In the "Short refs" thread, when Matthew implied that an SSK signature  
is verified at every node, my first thought was... cryptography is  
slow, and in a 'good' network such a verification would yield the same  
result 100% of the time.

If it is not already the case, perhaps it would make good sense to  
only verify the signature:
1) If we are the 'receiving' node. interested in it, or
2) If we are caching the network data locally, or
3) Statistically (1-in-every-N packets) to sanitize a 'bad' network  
(where N is probably related to HTL)

Otherwise, it would seem that the common case (where the data is only  
routed) would not require verification, as bad data would be verified  
'later' in the chain; better latency at the cost of a possibly  
avoidable transmission of bad data. Note that in the above case #2  
(the second-most-common case, I imagine) the check could be done after  
the network response; e.g. have one dedicated thread checking  
signatures & adding to the local cache (localizing the latency of  
crypto & disk I/O; freeing the OS resource of a thread).

Since somehow I got the subject of threads... :) and whereas we now  
will refuse requests to limit the number of threads freenet uses,  
threads effect the network. A load management system may take into  
account how many threads we can devote to a particular connection  
(which presumably is equivalent to the number of queued transactions).

--
Robert Hailey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://emu.freenetproject.org/pipermail/devl/attachments/20071130/36a9c6aa/attachment.htm