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
