On Friday 02 April 2010 17:43:25 Evan Daniel wrote: > On Fri, Apr 2, 2010 at 12:39 PM, Matthew Toseland > <toad at 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.
So this bug should be fairly high priority, despite its potentially being quite a lot of work?: https://bugs.freenetproject.org/view.php?id=4031 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100403/61f1f837/attachment.pgp>
