On Fri, Apr 2, 2010 at 12:39 PM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
On Friday 02 April 2010 17:31:13 Matthew Toseland wrote:
On Tuesday 09 March 2010 04:27:24 Evan Daniel wrote:
You should really send these to the support list; that's what it's for.
You can change the physical security level setting independently of
the network seclevels -- see configuration - security levels.
I'm not sure what else to suggest at this point. You could try
increasing the amount of ram for temp buckets (configuration - core
settings), but that's mostly a stab in the dark.
I suspect you need to reduce the amount of stuff in your queue.
Thanks Evan for helping Daniel. In theory it ought to be possible to have a
nearly unlimited number of downloads in the queue: That is precisely why we
decided to use a database to store the progress of downloads. Unfortunately,
in practice, disks are slow, and the more stuff is queued, the less of it
will be cached in RAM i.e. the more reliant we are on slow disks.
There are many options for optimising the code so that it uses the disk
less. But unfortunately they are all a significant amount of work.
See https://bugs.freenetproject.org/view.php?id=4031 and the bugs it is
marked as related to.
So I guess the real question here is, how important is it that we be able to
queue 60 downloads and still have acceptable performance? How many users use
Freenet filesharing in that sort of way?
All of them, I suspect. If a file is mostly downloaded, but not
complete, the natural response seems to be to leave it there in hopes
it will complete, and add other files in the mean time. Combined with
unretrievable files due to missing blocks, this will produce very
large download queues.
Evan Daniel
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
