Re: [Pan-devel] Re: CVS version and download speed

[robert mcdonald]

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 <address@hidden> 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/pan-devel
> 



        
                
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com