Download queue: split # of connections between two files

Want something added? Ask for it here.
Post Reply
matt314159
Newbie
Newbie
Posts: 21
Joined: February 13th, 2010, 2:45 am

Download queue: split # of connections between two files

Post by matt314159 »

Bad title, sorry. Perhaps I can explain.

This year as both my storage capacity and bandwidth has increased dramatically, I've been downloading a lot of 40-50GB files. I notice with my provider most of the especially old files will not even come close to saturating my line speed (200mbps). An older file will download closer to 100mb/s (13MB/s or so) leaving half my potential bandwidth wasted and bottlenecking my queue--It does not matter how many simultaneous nntp connections are enabled, total bandwidth remains roughly constant for that particular file. Interestingly enough, if I go and download that same file a second time, it always maxes out my connection speed. I've read people commenting on this phenomenon saying that it appears the providers move older articles to near line storage, and a retrieval triggers it to be moved back into hot storage or something like that, explaining the faster download on round two--forgive me, I know my terminology is way off.

Anyway, I figure a solution to this would be if I could split my total simultaneous server connections between two or more different files in the download queue instead of just hacking away at all the articles pertaining to one nzb until it's done at the slow speed.

I searched, and back in the days of 0.5 this same feature was requested, and the response was something akin to, "the download queue is already complicated enough as it is, sorry"--with the major 1.0 rewrite finally seeing the light of day, is there the potential that that answer has changed now?
User avatar
sander
Release Testers
Release Testers
Posts: 8811
Joined: January 22nd, 2008, 2:22 pm

Re: Download queue: split # of connections between two files

Post by sander »

Cool analysis. It looks like a kind of caching on the USP's side.

Answer to your question: No.

However ... this might be worth a try to simulate what you want (if only to verify your hypothesis): run two seperate SABnzbd instances, each with separate enviroments, so NO shared queues! On Linux I would do this with 1) two seperate user agents, each running SABnzbd on their own port or 2) with two docker instances each running SABnzbd.
You can then verify if you can saturate your line. :)
Post Reply