unstable downloadspeed

[nibor]

System Information:
Device name: CH3SNAS
CPU: 500Mhz
Memory: 64mb
Connection: 20mbit (aprox. 1.5MB/s)

Version: 0.3.1 Final
OS: Linux CH3SNAS 2.6.12.6-arm1 #28 Fri Jul 6 17:35:54 CST 2007 armv5tejl GNU/Linux
Install-type: python source
Template (if applicable): all
Firewall Software: None
Are you using IPV6? no
Is the issue reproducible? yes

Last night I've installed the newest version of sabnzbd but i noticed that the download speed is unstable.
My normal download speed is around 1.5MB/s but the highest speed i've achieved with sabnzbd was around the 1.2 ~ 1.3.
You're probl. thinking why would you complain if you still reach such speeds?
Check the following information: (this is a short log of ifstat)

Code: Select all

     egiga0
KB/s in    KB/s out
67.51        3.33
501.51      3.87
1177.00     20.40
171.28      3.00
905.25      7.50
29.30        0.98
515.14      4.86
122.64      2.98
586.83     11.87
709.73      8.35
722.35      7.53
313.66      3.99

As you can see the speed seems to be really unstable and with all the drops it wont be higher as 500 kb/s avg.
Beneath here you can see a " top " during downloading:

Code: Select all

top - 12:22:41 up 13926 days, 13:24,  2 users,  load average: 3.12, 2.62, 1.68
Tasks:  70 total,   5 running,  65 sleeping,   0 stopped,   0 zombie
Cpu(s): 12.5%us,  2.4%sy,  0.8%ni, 82.7%id,  1.3%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:     61948k total,    59972k used,     1976k free,    10684k buffers
Swap:  1060208k total,    12924k used,  1047284k free,    15584k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
21509 sabnzbd   16   0 72708  26m 1432 R 45.7 43.5   5:50.23 python
21507 sabnzbd   16   0 72708  26m 1432 S 12.2 43.5   1:24.16 python
21521 sabnzbd   16   0 72708  26m 1432 S  9.1 43.5   0:48.17 python
21514 sabnzbd   15   0 72708  26m 1432 S  6.1 43.5   0:47.27 python
22104 sabnzbd   15   0  2296  980  752 R  4.6  1.6   0:00.08 top
21512 sabnzbd   15   0 72708  26m 1432 S  1.5 43.5   0:07.33 python
21520 sabnzbd   15   0 72708  26m 1432 S  1.5 43.5   0:48.33 python

Also here there is nothing " strange / shocking " to see.
Playing around with the amount of connections 1 ~ 8 and the cache 0 ~ 200MB didnt solve it neither.
If there is more information needed for debugging just ask and i'll check it out.

Code: Select all

Download Dir: 822.27 GB - Complete Dir: 822.27 GB - Download speed: 450.02 KB/s - Queued: 25.02/201.25 MB

[switch]

Could you please verify if going back to 0.3.0 you get full speeds again to rule out any ISP/Newsgroup provider speed problems. And also post the ifstat output for 0.3.0

As far as I am aware, nothing was changed between 0.3.0 and 0.3.1 in the download code, so I cannot think of any reason for the changes at the moment.

[nibor]

Thanks for the fast reply switch.
I did forget to notice in the post that this machine never runned an earlier version of sabnzbd.
Ive installed version 0.3.0 but it got the same problem.

Code: Select all

CH3SNAS:~# ifstat
      egiga0
 KB/s in  KB/s out
   34.28      2.60
  405.31     75.14
  349.34      9.09
  472.63     12.83
  689.71     88.23
  187.67      5.07
  479.84     34.63
  719.53     61.04
  483.43     11.26
  888.90     86.86
  533.61     10.06
  919.37     18.61
 1158.19     90.32
  361.31      7.68
  853.32     84.45
 1052.02     28.24
  801.58     16.33
  348.67     76.71
    1.01      1.42
    1.36      4.98
    2.77     70.73
    1.39      7.17
   73.51     63.16
   97.90     10.63
  404.65     12.53
    1.98     68.29
    0.26      1.51
    0.26      2.17
    1.59     66.82
   65.97      4.27
  442.94      6.84
  567.20     87.41
  966.40     20.33

The connection ISP/Newsserver seems to be stable can download 1.2 ~ 1.5 mb/s stable on different pc.
Currently im trying to install nzbperl to see if it got the same problems on this box.
You got some more suggestions/ideas?

Another thing i saw in my logfile:

Code: Select all

2008-02-17 16:14:29,909::INFO::[downloader] Thread [email protected]:119: [email protected] done
2008-02-17 16:14:29,915::INFO::[downloader] Delaying
2008-02-17 16:14:30,326::INFO::[downloader] Thread [email protected]:119: [email protected] done
2008-02-17 16:14:30,335::INFO::[downloader] Delaying
2008-02-17 16:14:30,347::INFO::[downloader] Thread [email protected]:119: [email protected] done
2008-02-17 16:14:30,354::INFO::[downloader] Delaying

Is the delaying normal behaviour ?

[shypike]

Most likely cause is that the NAS/SABnzbd cannot keep up with the download speed.
It frequently needs to pause the downloader to process the received data,

Set logging to maximum (command line switch -l2) and look for "delaying" and "undelaying" in the logging.
This means that SABnzbd has to pause the downloader because it cannot keep up.

Older releases had memory leak here, because the queue between the downloader and
the processing overflowed.

Enlarging the article_cache will help speed thing up, but be careful to avoid heavy disk-swapping,
this is counterproductive.

[nibor]

I suppose there is not much else to do about the delaying except enlarging the cache file?
I've tried 0 ~ 200mb cache file but without result.
Also as you can see in ifstat it doesnt reach the max speed of my connection.

[neilt0]

Why would you use a cache of 200MB when you have 64MB of RAM?

You'd be better off with no cache, or 30-40MB cache at the most.

How many connections are you using? I use 8 to 10 to max out my line, this will partly depend on your route to the news server.

You won't get 100% of your connection speed with a 500MHz ARM9 and 64MB.

My LinkStation Pro is a 400MHz ARM9 with 128MB RAM and I can squeeze about 50 to 75% of my 20mbit connection through it. Which is why I use two NAS devices to max out the line... 

With 128MB RAM, I use 55MB-70MB cache. Don't forget that unrar and par2 also require RAM.

[nibor]

I've started with 0 cache this didnt workout so i slowly moved it up to see differences.
Same counts for the amount of connections normally i use 4 connections but i've tested it with 1 ~ 8 not much difference.
But with 500mhz and 64mb you still should have more as ~500kb/s avg. right?

Code: Select all

  166.93      6.67
 1576.46     48.53
 1232.37     32.67
 1449.54     29.59
  329.78      4.60
    0.13      0.19
    0.13      0.19
    0.13      0.22
   12.57      1.71
 1376.46     33.91
 1559.56     34.48
 1361.36     26.45
  415.50      6.25
    0.13      0.19
    0.13      0.19
    0.13      0.19
    0.13      0.19

It looks like a cyle which is playing over all the time if you see the amount of data.

[nibor]

Update:
I've been playing a bit around with all kind of settings and ended up by a full format of the NAS.
Removed the RAID setup to see if there was any difference but it became worse.
Load did go upto 4 ~ 5  which was causing alot of " command lag " on the machine itself.
Then i decided to try around with a different downloader called " hellanzb " you can see the ifstat of it below here:

Code: Select all

CH3SNAS:/opt# ifstat
      egiga0
 KB/s in  KB/s out
 1403.90     16.47
 1278.92     25.79
 1046.55     70.82
 1479.62    189.67
 1047.40    148.30
 1375.45    137.69
 1353.69     13.90
 1165.61     31.31
 1271.72     14.64
 1394.42     17.23
 1375.62     27.80
 1497.22     29.41
 1603.56     33.41
 1388.70     20.22

This means that the NAS is capable of downloading/processing at highspeed even with the not perfect specs.
Any developer who can look into the matter of the dropdowns?
Ofcourse i got an alternative now but i still would love to use sabnzbd and if needed i can test things.

[neilt0]

In my tests, HellaNZB is slower.

It's faster to download, then takes forever to assemble articles -- unlike SAB, it doesn't assemble on the fly.

I actually spent a long time benchmarking both. See here:

http://forum.nas-central.org/viewtopic. ... 686#p45686

If you benchmark both and find Hella to be faster (overall, including assembly and unpacking stages), let me know.

[nibor]

Im quite sure that if i would bench them both hella would win at this moment.
Simply cause its 3x as fast downloading (1.4 ~ 1.5MB/s  ipv 400 ~ 500 kB/s).

[neilt0]

As I said, it's faster to download, then takes forever to assemble articles -- unlike SAB, it doesn't assemble on the fly.

Benchmark both.

[nibor]

I'll try to do some decent benchmarks the upcoming days but of what i've experienced the decoding of the articles didnt take that long.
But i'll test more when im back at home.

Question for the developers of sabnzbd: why did you choose to do the decoding on the fly? Its a performance boost or? In the new version 0.4.0 will there be an option to do this afterwards? I think it would be a nice addition since your line will be longer "empty" so you can use it for other things.

[shypike]

I'm not sure why this was decided.
It's something the original author did between 0.2.4 and 0.2.5.
As far as I know it is beneficial for situations where the bandwidth is the limiting factor.
If the PC is fast enough it can do decoding while still receiving more data.
When the CPU (or disk) is the limiting factor, this may work out different.

We will have a critical look at this for a future release.

On the other hand, if processing is the bottleneck (instead of bandwidth), why do you
prefer to have the highest possible download speed?
Personally I would prefer a lower average line saturation.
If a job takes 2 hours to download anyway, I would rather have it at 50% download speed
during these 2 hours instead of 100% speed during the first 1 hour plus a post-processing phase
of another 1 hour.

[nibor]

I mostly use this "NAS" for burst downloading, after that i want to have my line free again.
This is needed due some other tasks/jobs running at this connection.
But i doubt it will take 2 hours to decode everything it should take aprox 10 - 20 min. for a 600mb file at max.
It would be great if there is an option to do it afterwards in a future release :-)
If you need some tester for it to benchmark on a NAS system count me in.

[neilt0]

Not decoding on the fly won't necessarily help, Hella does that and the problem comes when you have more than one item in the queue -- when item 1 has finished do you then decode item 1 and download item 2? If you do, you're back to parallel processes!

Your only option would be to either pause item 2 while you decode item 1 or download the entire queue and then decode the lot.

This isn't particularly efficient and I can't think of another program that works the way Hella does.

Either way, you're going to have to wait for the CPU at some point, and I found the way Hella did it to be painfully slow.

Hella is better if you want to release the bandwidth for other apps, but I personally want my usenet downloads to process quickly, and SAB does this better than Hella.

The only issue with SAB comes where you have the combination of very high download speeds and low CPU performance.
Given that SAB can max out a 10mbit line on my NAS, I think it's about as good as we'll get unless something's written in assembler or optimised in some clever way that I can't think of.

I'd like someone else to run some benchmarks on a NAS in case my Hella install is broken.
If you scroll through the discussion on NAS-Central, you'll see that the guy I was discussing this with was insistent that Hella was quicker and my Hella install was borked, but then didn't actually run any benchmarks...

Might be worth putting an .ini switch in for testing purposes and then I'd be happy to test the serial decoding option on a NAS.

I was looking at SourceForge last night -- can we download nightly (source) builds for testing from there?