On Thursday 10 January 2008 22:27, Victor Denisov wrote: > |> I can retrieve most pictures on the queue through Fproxy, and they > |> usually took no more than 10-15 seconds to show up. However, those same > |> files sit in the queue for more than 5 days (the node was up almost > |> 24x7, save for reboots and just a couple of hours of outage), with > |> various degrees of progression (mostly, 50-70%). Some hadn't been > |> touched at all, it seems (they're completely gray, with italicized 0% > |> progress). > | > | Possibly a bug - when you visit them in fproxy, the node should > immediately > | pass them along to the waiting clients. > > Is there anything I can do to help troubleshoot this problem? Also, I > feel there are two independent problems here: > > - files being retrieved by Fproxy not made available to other clients in > a reasonable time; > - files not being completely downloaded by the queue manager in about 5 > days, then successfully retrieved by Fproxy in a matter of seconds; > > Is there anything I can do to help troubleshoot this? > > Also, I think there's a definite lack of information on the queue page > (see below). > > |> Is that an expected behavior? How does the node choose what block of > |> what file to download next? Does it try local cache first? Could it be > |> that large files (with lots of blocks) choke small files? > | > | No, it should round-robin between them.. if it's tried them lots of > times and > | not got anywhere, or if they are at a lower priority, they may not be > | attempted for ages. > > Hmm. Interesting. All files were at "low" priority, set by default by > Thaw. Is that ok, or should I set default priority to be higher? > > To better understand how the queue fares, I think the following > information would be helpful: > > - average availability of each queue item (total number of blocks > retrieved divided by the total number of block retrieval attempts); > - total number of download attempts for the item; > - items which are being retrieved right now; > - timestamps related to the item (entered queue, first successful block, > last successful block, last retrieval attempt); > > Perhaps, in "simple" mode, the above can be summed into a generalized > "availability" metric (i.e., "good", "average", "poor", "unretrievable"). > > Is there a way to gather such information post mortem, from the log > files? Should I increase logging level to achieve this? > If not, perhaps I can try and see if I'll be able to understand how the > queue manager works, to add this functionality - where should I start > looking?
We accept patches. We even give out SVN access reasonably easily. > > Regards, > Victor Denisov. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/support/attachments/20080111/54f99220/attachment.pgp>
