Re: [Pan-users] Policy discussion: GNKSA

[Rob]

On Monday 04 July 2011 11:42, Alan Meyer wrote:
> Of course in theory, theory and practice are the same.  But in
> practice ... maybe I'm totally screwed up here.

Practically speaking, I hit binsearch.info and found an Ubuntu ISO to test 
with, currently the first result here:

http://binsearch.info/?q=ubuntu-10.04.1-desktop-
i386.iso&max=100&adv_age=600&server=

(you'll need to fix the word-wrapped URL).  I was going to post the result 
of 10 connections, 4 connections and 1 connection, but we have dinner 
guests arriving shortly and the single-connection one is still going.  Each 
time, I created a new directory, put the nzb file into it, purged Pan's 
article cache, adjusted the max connections to the appropriate number and 
watched jnettop to verify it was working after issuing the following 
command line:

time pan --no-gui --nzb ubuntu\ iso.nzb -o `pwd`

I did 10 connections first, so that if there were any server-side caching 
it would be disadvantaged.

real    14m1.951s
user    1m46.775s
sys     0m31.602s

Then, 4 connections.

real    35m31.818s
user    4m37.997s
sys     1m11.544s

So, you save 60% of the download time using 10 connections vs. 4.  It's 
been 25 minutes and the single-connection one is still going.  It may be 
worth noting that the NZB created by the above query creates 2 copies of 
the ISO, which is probably why it took 15 minutes to download and decode a 
700MB ISO.

This was using Giganews, a service which advertises 20 simultaneous 
connections for its lowest-end subscription level.  For my subscription 
level, it advertises 50 simultaneous connections.  

Whether it's my ISP, Giganews, my router or something else throttling 
things on a per-connection basis, the only conclusion I can come up with is 
that Pan's attempts at GNKSA compliance are hamstringing its binary 
performance relative to more modern newsreaders, except for those of us who 
are comfortable tweaking XML files by hand.

Rob