The fix: change SECONDS_TO_SLEEP_ON_EAGAIN (found in pan/nntp.c) to something lower (I got 150KB/s at the default [0.75], I reduced it to 0.1 and got 800+KB/s).
The explanation: Each time the buffer is exhausted, GIOChannel returns an EAGAIN (G_IO_STATUS_AGAIN) and we wait SECONDS_TO_SLEEP_ON_EAGAIN before retrying the read. This results in a ton of time where we're not reading any data at all, killing our throughput. 0.75 seems like an eternity to me, but it might be a reasonable setting on a slow network (dialup?). --- Tom Dexter <[EMAIL PROTECTED]> wrote: > > > > I have noticed this slowdown also. > > > > When getting smallish jpg files the slowdown is > almost 50%, When getting > > larger rar (5-15MB) files the slowdown is around > 10%. > > > > When decoding and saving monster 50-100MB files > download actually stops > > for the duration of the decode and save operation. > > > > I suspect this is all because of the new single > thread model used by the > > program. On a slow network connections this would > not be so bad, but > > faster networks will fill up TCP windows and block > during disk I/O. > > > > mk > > > > Even if the download does in fact stop during the > decode and save, I don't > think that's the cause of what I'm seeing. When I > download large rar > files using one server thread, the 0.14.2 version > will generally download > as 800 to 900 KB/Sec, and the CVS version is > consistently 1/4 that speed > or slower. > > Tom > > > > > _______________________________________________ > Pan-devel mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/pan-devel > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com _______________________________________________ Pan-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-devel
