-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 |> 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? Regards, Victor Denisov. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHhpvXS81Mh9/iCDgRAne7AJ9Lm8knuARbE5BL++f6gqHuP6NslwCg1Ehp VupZ5O2OYe0GRL5HoisPJXY= =fanl -----END PGP SIGNATURE-----
