Seeding priority by tracker

[ccrisvuze]

Hello,

I studied as much as I could the VUZE Wiki, forum, etc., but I was not able to find the answer to my quest.  If the answer is obvious and I have missed it in my research, I apologize.

I familiarized myself with the seeding rules.  The parameters seem to be ratio, number of seeds, peers, time, etc.

The parameter of most interest to me is: TRACKER.
I want to prioritize seeds by tracker.  
Explanation:
On some interesting trackers (let's call these Priority #1), ratios are very "precious" (very interesting downloads but few and far between uploaders).  I want my pipes to be wide open for these trackers, no matter if I have reached a 20:1 ratio for a specific torrent or have been on seed for 5 years.  In a situation with many simultaneously uploading torrents, I want these guys to get most of my bandwidth (and the other guys to get less or no bandwidth).  In other words, I don't want to miss one byte of uploaded data to these trackers.
Priority #2 would be most of other trackers.
Priority #3 would be ratioless trackers and public trackers.  I like to let the seeds sit for these guys indefinitely.  If there is nothing uploading of higher priority, than let these guys upload as much as they want (even if the tratio gets to be 20:1).  However, in a situation of many uploading torrents, I want these guys to move to the bottom of the queue (or disconnect) and let Priority #1 build ratio for me (and allow some of Priority #2 at lower bandwidth).  When the "important" guys are done uploading, then these Priority 3 seeds are free to pop up the queue and get more bandwidth.

If there can be a "global" way of prioritizing the trackers like above, that would be great (more automation, less maintemance work for me).
Even if that is not possible to do globally, I could do it manually, on a "per torrent" basis (designate each torrent as Priority #1 or #2 or #3).

Does anyone know if this is possible (and how)?

Thanks and best wishes.

[GaryE]

Well you can set up speed limits per torrent.  Just right click on the torrent and choose "Upload Speed Limit" and make it whatever you want.  But I do not think that is what you want to do.

You could set up Vuze so that you queue any downloads over a certain ratio (say 1.5 or something) then for the higher priority torrents you could "Force Seed" those torrents.  But that is kind of indiscriminate and it is probably not what you seem to want.

I think you want unlimited bandwidth to go to the lowest priority torrents until which time there are second priority torrents which need seeds and then the second priority torrents get unlimited bandwidth while the lowest priority torrents only get . . . say 3% of your max upload speed.  Then when first priority torrents need seeds those get unlimited bandwidth the second priority torrents get say 15% of max upload speed and the lowest priority torrents get 3% of max upload speed.  Or something along those lines.  I guess what would be ideal would be for the first priority to get all of the bandwidth they need and any left over bandwidth goes to the second priority torrents then any leftover bandwidth goes to the third priority torrents.  I think I have that right.

The short version is that I do not know if what you are asking is possible.  There might be some creative workarounds to implement something like the first example I gave but I think that will be it.

I will be interested to hear what the Vuze staff/coders say.

[ccrisvuze]

Well you can set up speed limits per torrent.  Just right click on the torrent and choose "Upload Speed Limit" and make it whatever you want.  But I do not think that is what you want to do.

You could set up Vuze so that you queue any downloads over a certain ratio (say 1.5 or something) then for the higher priority torrents you could "Force Seed" those torrents.  But that is kind of indiscriminate and it is probably not what you seem to want.

I think you want unlimited bandwidth to go to the lowest priority torrents until which time there are second priority torrents which need seeds and then the second priority torrents get unlimited bandwidth while the lowest priority torrents only get . . . say 3% of your max upload speed.  Then when first priority torrents need seeds those get unlimited bandwidth the second priority torrents get say 15% of max upload speed and the lowest priority torrents get 3% of max upload speed.  Or something along those lines.  I guess what would be ideal would be for the first priority to get all of the bandwidth they need and any left over bandwidth goes to the second priority torrents then any leftover bandwidth goes to the third priority torrents.  I think I have that right.

The short version is that I do not know if what you are asking is possible.  There might be some creative workarounds to implement something like the first example I gave but I think that will be it.

I will be interested to hear what the Vuze staff/coders say.




 

Hi GaryE,

Thanks for responding.

I thought of doing what you suggested first, but, as you mentioned, it wasn't exactly right.

Your description after "I think you want..." is exactly what I want.
Highest priority/bandwidth to my "Tier 1" torrents, etc.

On "another" bittorrent client I have used, one can assign a "priority" value from 1 to 10 to each torrent.  I would assign priority 10 to my "Tier 1" torrents, priority 1 to ratioless or public torrents and priority 5 to everyone else (or some other values inbetween).  Then the bittorrent client juggles the bandwidth dynamically: when things get very busy, the "10s" get most of the bandwidth.  When things are slow, even the "1s" get full bandwidth.  That way I am fair to everyone and I can keep many seeds alive: the "Tier 1" seeds get served fast (and I build my ratios) while "Tier 3" uploaders will simply have to stay a bit longer on the download, but they are covered, too.

The "other" bittorrent client is not allowed on most private trackers.  Also, I prefer Vuze, so being able to prioritize in this manner in Vuze would be great.

Thanks.

[parg]

Vuze's seeding rules are oriented towards getting all torrents to their target seed-ratio and prioritizes based on which ones have the most work to do - if you haven't done so then enable the 'seeding rank' column in the Library to see how each download is currently ranked.

While doing this it also limits the number of actively seeding torrents to reduce overall resource usage and will rotate the active ones that aren't doing much in an attempt to find torrents where upload is possible.

You can control various aspects of this via the overall Queue options (max active, rotation period etc) and you can also set individual target share ratios on downloads or on particular tags (along with a 'minimum share ratio')

You can override all of this behaviour via 'force start' - this just causes the download to be permanently active.

You can also auto-assign downloads to tags based on tracker URL.

There is also a generic 'upload priority' that can be assigned to a tag that give those torrents priority in terms of upload scheduling at the network dispatch level (bytes queued for upload for priority torrents will take precedence over non-priority ones) .

The above is just a recap of things that can affect upload (not necessarily complete or 100% accurate :)

I don't think the current features can be combined to achieve exactly what you're looking for - the closest I can think of is to create a tag for your high priority torrents and perhaps auto-assign downloads to it based on tracker-url. Manually ensure that all torrents assigned to that tag are 'force start' and set 'upload priority' for that tag.

This would at least ensure that your high-priority downloads are always running and give them some advantage in uploading. Of course if you have a large number of high-priority torrents then force starting them all is going to use more resources.

To do the job properly you would probably need to write a plugin to juggle with speed limits...

[parg]

If you want to spend some time thinking about how a bandwidth adjustment algorithm might work, that would be interesting.

You could assume that the various priority categories are denoted by tags A,B,C,... and that the only controls you have are to

1) set explicit upload rate limits on tags
2) periodically look to see what the currently achieved upload rate is for a tag

So, for example, assuming only two tags A and B - tag A has unlimited upload rate (highest priority), tag B is for all the other downloads

Start B with an upload limit of 5KB/sec

Wait a bit and see what is achieved for B. If it is < 5KB/sec then don't do anything. If it is 5KB/sec then make a note of the currently achieved rate for tag A and increase B to 10. 

Wait a bit to see if tag A's achieved upload rate has dropped significantly. If not then increase B to 15 otherwise drop B back to 5.

How would this work with 3 or 4 levels? What should the increase steps be etc.

If your max upload was 1MB/sec and steps of 5KB/sec and wait times of 30 seconds were used, would it be acceptable to wait for around 1.5 hours for B's rate limit to be raised to fully use your upload? Or perhaps it should be a binary chop based approach, in which case a decent upper limit would need to be configured.

etc.etc.

[ccrisvuze]

Thanks to the two contributors who have understood my query and offered input.

I have done further research and have seen that manually assigning a priority value (such as HIGH, MEDIUM or LOW) to torrents is a quite common feature in bittorrent clients.  I have not been able to find a similar setting in VUZE.

I have also tried implementing my idea in VUZE by assigning upload speed caps.  Although it does move prioritizing of seeds in the direction I am interested in, it is still crude. With fixed caps, I "sentence" many/most torrents to a permanently very low upload speed (such as 10 kb/s).  It somewhat fits my purpose, but if I am the only seed and a downloader attempts a full BD download, I "sentence" him to a month long download (while my bandwidth at times will be underutilized).   And such... (3 "high priority" uploads sharing bandwidth with 20 "low priority" 10 kb/s uploads, when it would work much better if the "low priority" torrents would pause).

I submitted the following idea in the torrenting section on Vote for Vuze" section, as directed.

Intelligent/Assignable Seeding Priority by Tracker (Available Bandwidth Seeding)

We already have seeding priority by ratio, peers, etc.  What VUZE doesn't have (and other clients do) is an assignable IMPORTANCE value for each seed with bandwidth management of seeding.

EXPLANATION
Most torrenters seed only until such time that their ratio obligation (or goal) is fulfilled, than delete.  This is convenient for the individual, but a bit selfish.  This leaves trackers with loads of dead torrents, many of them very interesting and very hard to find.  I committed to keep everything I download on seed indefinitely.  This can be done with intelligent/assignable priority and bandwidth management.

HIGH PRIORITY
Some seeds are extremely precious (1. on very good trackers with very little upload/download activity - I want to capture every bit of ratio;  2. trackers with very strict ratio rules - I want to capture every bit of ratio).  I would assign these seeds a HIGH priority.  When a seed starts uploading in this category, it should get my full bandwidth.  All lower priority seeds should get proportionately a lower percentage of my bandwidth.

MEDIUM PRIORITY
These are for trackers where I have a very good ratio or for seeds that have already reached a certain goal (such as 3:1).  When a seed starts uploading in this category, It should share the bandwidth nicely with all others, but decrease bandwidth if a HIGH PRIORITY seed kicks in.

LOW PRIORITY
These are for ratio-less trackers and for trackers I have an unbeatable ratio or seeds that have been downloaded over a certain goal (such as 10:1).  When a seed starts uploading in this category, It should get full bandwidth if no other higher priority seeds are uploading.  If a higher priority seed kicks in, it should decrease bandwidth.  If many higher priority kick in, the low priority seeds should pause, until such time as the higher priority seeds have finished.  

Instead of deleting torrents after reaching a goal (could be only DAYS), many/most seeds would end up here (for perhaps YEARS).  Even with hundreds/thousands of torrents seeding, it is a random game of chance what seed gets downloaded and when.  There are times when there is no activity for HIGH or MEDIUM priority torrents, at such times the LOW priority guys should use my entire bandwidth.  However, here comes the HIGH priority seed I've been waiting for weeks to upload: move over lower priority torrents, let this guy upload at my max bandwidth.  Soon he will be finished, so the lower priority torrents kick in again and folks happily finish their downloads.

I submit to you: for the general interest of torrenting (long term), what is better: stopping seeding when your personal goal was reached (and having lots of dead seeds) or continuing to seed on an "available bandwidth" basis.  The upload/download may be slower, but it will complete.  

Remember also that the more people adopt this seeding strategy, the effect is cumulative: instead of having only 1 (one) very slow "available bandwidth" seed (me), you'd have many more people like me "available bandwidth" seeding, so a download may actually move pretty fast between all of us.  

Remember also that the more people adopt this seeding strategy, the more live and healthy torrents we would encounter (with fewer dead torrents).

An implementation of this strategy would provide for three priority values:
HIGH
MEDIUM
LOW
A more refined implementation would provide 10 priority values: 1 for highest priority, 10 for lowest priority (or the other way around...) and all other numbers in between.

A good implementation of this strategy would provide for both automated and manual controls:

Automated controls
Assign a tracker (by URL) a certain priority value.  After downloading, all torrents move to seeding to the pre-assigned priority value.
Of course, new or non-assigned trackers would be assigned a middle priority value until such time as a priority value is assigned to the tracker (URL).
This would be good in most instances and save a lot of operator time.

Manual control (override)
Assign a torrent a certain priority value, overriding the automated assignment.
This would be good for over downloaded torrents (you are already at 20:1 on this one, don't delete the torrent, move it to the low priority zone).
If you see that someone has been struggling for a week to complete your only one seed at very low speed, crank it up to a higher priority for a while.

Thanks for your consideration.

[parg]

Latest beta has an initial hack at allocating up/down bandwidth based on Tag assignments.

It is controlled by adding lines of the following form to the speed limit scheduler config:

Code:

priority_up/down [<num>=<tagname>,]+freq=<freq>,max=<rate>

<num> is currently irrelevant, just use 1,2,3..
<tagname> is a tag name, priority is in order of appearance
<freq> is how often things are checked in seconds
<rate> is the maximum rate that will be allocated to each tag

e.g.

Code:

priority_up 1=tag1,2=tag2,3=tag3,freq=5,max=20K

This gives highest upload priority to tag1, next highest tag2 and lowest tag3. It checks things every 5 seconds and will allocate 20K/sec to each tag.

Activity is logged to the Speed Limit Handler log view (under Tools->Plugins->Log Views->Speed Limit Handler)

I got distracted for a few weeks after starting it and am stuck on some other stuff at the moment, but if you want to play with it then please have a go!

[ccrisvuze]

Latest beta has an initial hack at allocating up/down bandwidth based on Tag assignments.

It is controlled by adding lines of the following form to the speed limit scheduler config:

Code:

priority_up/down [<num>=<tagname>,]+freq=<freq>,max=<rate>

<num> is currently irrelevant, just use 1,2,3..
<tagname> is a tag name, priority is in order of appearance
<freq> is how often things are checked in seconds
<rate> is the maximum rate that will be allocated to each tag

e.g.

Code:

priority_up 1=tag1,2=tag2,3=tag3,freq=5,max=20K

This gives highest upload priority to tag1, next highest tag2 and lowest tag3. It checks things every 5 seconds and will allocate 20K/sec to each tag.

Activity is logged to the Speed Limit Handler log view (under Tools->Plugins->Log Views->Speed Limit Handler)

I got distracted for a few weeks after starting it and am stuck on some other stuff at the moment, but if you want to play with it then please have a go!

 

Absolutely awesome!
Thanks a million!
I am going through a bit of a rough spot at work right now but as soon as I clear my backlog (5-7 days) I will give this a thorough test drive and will report back in detail.
Once again: Thanks!

[ccrisvuze]

Here is what I have done:

- Created 10 Tags, named:
Priority_01
Priority_02
Priority_03
Priority_04
Priority_05
Priority_06
Priority_07
Priority_08
Priority_09
Priority_10

- There are approx 700 torrents, on 20 trackers. Assigned all trackers to Tags Priority_01 through Priority_09 (Priority_10 not used yet).
Priority_01 are my most important trackers (ratios hard to come by).
Priority_09 are trackers I do not need ratio, I am doing "community service".
In between tags are proportionate.

- Using Library view showing all torrents.  All torrents set on super seeding, no other rules apply, unlimited upload/download speed.  Sorting by "Up speed" in descending order.  Have created a column for Tags.  

- Have opted into Beta, installed Beta (V5.6.2.1_B03).

- Initially let program run without any scheduled speed limits to verify installation and see what is uploading and at what demand level.  Installation OK.  Vuze shows approx 12 torrents uploading, taking up the maximum upload bandwidth of my plan (which is OK with me, as there is plenty "residual" bandwidth left over for casual web browsing and there is no lag to interfere with normal operations).  The  bandwidth order Vuze assigns (from highest to lowest) depends entirely upon available seeds, peers, peer download speed, what tracker decides, etc..  As a result, there is no correlation between my desired hierarchy and bandwidth allotment.  All working as expected.

- Added the following lines to Speed Limit Scheduler:

Code:

enable=yes
priority_up 1=Priority_01,2=Priority_02,3=Priority_03,4=Priority_04,5=Priority_05,6=Priority_06,7=Priority_07,8=Priority_08,9=Priority_09,10=Priority_10,freq=5,max=20K

Result:
Each Tag is now limited at 20K upload.  The order is the same as before (depends entirely upon available seeds, peers, peer download speed, what tracker decides, etc.).  It has nothing to do with the desired hierarchy.  However, the total upload bandwidth has decreased dramatically as now each of the 10-12 uploading torrents goes only to max 20K.  Waiting does not change individual torrent bandwidth or overall hierarchy.  

At one point the hierarchy was almost backwards, so I tried reversing the order of tags:

Code:

priority_up 1=Priority_10,2=Priority_09,3=Priority_08,4=Priority_07,5=Priority_06,6=Priority_05,7=Priority_04,8=Priority_03,9=Priority_02,10=Priority_01,freq=5,max=20K

Nothing changed in hierarchy or bandwidth.

Finally, thinking that perhaps this works by reducing an initial bandwidth value, I changed to 
max=600K 

This accomplished nothing, other than giving each torrent maximum available bandwidth, up to 600K.  As expected, total bandwidth increased.  The overall hierarchy did not change.

All throughout testing I verified:
1) Speed limits>View Current
This only showed something like this:

Code:

Tag Limits
   Manual - Priority_05: Up=20.0 kB/s, Down=Unlimited
   Manual - Priority_04: Up=20.0 kB/s, Down=Unlimited
   Manual - Priority_03: Up=6.9 kB/s, Down=Unlimited
   Manual - Priority_02: Up=20.0 kB/s, Down=Unlimited
   Manual - Priority_01: Up=20.0 kB/s, Down=Unlimited
   Manual - Priority_10: Up=20.0 kB/s, Down=Unlimited
   Manual - Priority_09: Up=20.0 kB/s, Down=Unlimited
   Manual - Priority_08: Up=20.0 kB/s, Down=Unlimited
   Manual - Priority_07: Up=20.0 kB/s, Down=Unlimited
   Manual - Priority_06: Up=20.0 kB/s, Down=Unlimited

For what is worth, the speed limit handler log shows:

Code:

[21:43:59] tag_priority: Priority_02: ->-1
[21:43:59] tag_priority: Priority_03: ->-1
[21:43:59] tag_priority: Priority_04: ->-1
[21:43:59] tag_priority: Priority_05: ->-1
[21:43:59] tag_priority: Priority_06: ->-1
[21:43:59] tag_priority: Priority_07: ->-1
[21:43:59] tag_priority: Priority_08: ->-1
[21:43:59] tag_priority: Priority_09: ->-1
[21:43:59] tag_priority: Priority_10: ->-1
[21:44:04] tag_priority: Priority_04: ->614400
[21:44:04] tag_priority: Priority_07: ->614400
[21:44:04] tag_priority: Priority_08: ->614400
[21:44:04] tag_priority: Priority_09: ->614400
[21:44:04] tag_priority: Priority_10: ->614400
[21:44:34] tag_priority: Priority_01: ->614400
[21:44:54] tag_priority: Priority_01: ->3994
[21:45:14] tag_priority: Priority_02: ->614400
[21:45:34] tag_priority: Priority_02: ->79806
[21:45:54] tag_priority: Priority_03: ->614400
[21:46:14] tag_priority: Priority_03: ->43601
[21:46:35] tag_priority: Priority_05: ->614400
[21:46:55] tag_priority: Priority_05: ->497921
[21:47:15] tag_priority: Priority_06: ->614400
[21:47:34] tag_priority: Priority_06: ->3215
[21:47:44] tag_priority: Priority_01: ->614400
[21:47:54] tag_priority: Priority_02: ->75883
[21:47:54] tag_priority: Priority_03: ->28736
[21:47:54] tag_priority: Priority_05: ->355268
[21:47:54] tag_priority: Priority_06: ->2142
[21:48:14] tag_priority: Priority_02: ->72692
[21:48:14] tag_priority: Priority_03: ->21575
[21:48:14] tag_priority: Priority_05: ->343061
[21:48:34] tag_priority: Priority_03: ->18759
[21:48:34] tag_priority: Priority_05: ->333591
[21:48:36] tag_priority: Priority_10: ->0
[21:48:36] tag_priority: Priority_09: ->-1
[21:48:36] tag_priority: Priority_08: ->-1
[21:48:36] tag_priority: Priority_07: ->-1
[21:48:36] tag_priority: Priority_06: ->-1
[21:48:36] tag_priority: Priority_05: ->-1
[21:48:36] tag_priority: Priority_04: ->-1
[21:48:36] tag_priority: Priority_03: ->-1
[21:48:36] tag_priority: Priority_02: ->-1
[21:48:36] tag_priority: Priority_01: ->-1
[21:48:39] tag_priority: Priority_10: ->614400
[21:48:39] tag_priority: Priority_09: ->614400
[21:48:39] tag_priority: Priority_08: ->614400
[21:48:39] tag_priority: Priority_07: ->614400
[21:48:39] tag_priority: Priority_04: ->614400
[21:48:39] tag_priority: Priority_01: ->614400
[21:49:04] tag_priority: Priority_01: ->1024
[21:49:24] tag_priority: Priority_10: ->614400
[21:49:24] tag_priority: Priority_09: ->614400
[21:49:24] tag_priority: Priority_08: ->614400
[21:49:24] tag_priority: Priority_07: ->614400
[21:49:24] tag_priority: Priority_04: ->614400
[21:49:30] tag_priority: Priority_06: ->614400
[21:49:30] tag_priority: Priority_05: ->-1
[21:49:30] tag_priority: Priority_03: ->-1
[21:49:30] tag_priority: Priority_02: ->-1
[21:49:30] tag_priority: Priority_01: ->-1
[21:49:50] tag_priority: Priority_06: ->-1
[21:50:10] tag_priority: Priority_05: ->614400
[21:50:30] tag_priority: Priority_05: ->432333
[21:50:50] tag_priority: Priority_03: ->614400
[21:51:10] tag_priority: Priority_03: ->8881
[21:51:30] tag_priority: Priority_02: ->614400
[21:51:45] tag_priority: Priority_01: ->614400
[21:51:50] tag_priority: Priority_02: ->64528
[21:52:10] tag_priority: Priority_05: ->417030
[21:52:10] tag_priority: Priority_02: ->64186
[21:52:30] tag_priority: Priority_05: ->413385
[21:52:50] tag_priority: Priority_05: ->400753
[21:52:50] tag_priority: Priority_02: ->56206
[21:53:09] tag_priority: Priority_05: ->389923
[21:53:29] tag_priority: Priority_05: ->389597
[21:53:49] tag_priority: Priority_05: ->375862
[21:53:49] tag_priority: Priority_02: ->55131
[21:54:25] tag_priority: Priority_06: ->614400
[21:54:25] tag_priority: Priority_05: ->372570
[21:54:25] tag_priority: Priority_03: ->6831
[21:54:25] tag_priority: Priority_02: ->52511
[21:54:45] tag_priority: Priority_06: ->94689
[21:55:04] tag_priority: Priority_05: ->614400
[21:55:04] tag_priority: Priority_03: ->4766
[21:55:04] tag_priority: Priority_02: ->49824
[21:55:24] tag_priority: Priority_05: ->335045
[21:55:29] tag_priority: Priority_01: ->0
[21:55:29] tag_priority: Priority_02: ->-1
[21:55:29] tag_priority: Priority_03: ->-1
[21:55:29] tag_priority: Priority_04: ->-1
[21:55:29] tag_priority: Priority_05: ->-1
[21:55:29] tag_priority: Priority_06: ->-1
[21:55:29] tag_priority: Priority_07: ->-1
[21:55:29] tag_priority: Priority_08: ->-1
[21:55:29] tag_priority: Priority_09: ->-1
[21:55:29] tag_priority: Priority_10: ->-1
[21:55:29] tag_priority: Priority_01: ->20480
[21:55:29] tag_priority: Priority_04: ->20480
[21:55:29] tag_priority: Priority_07: ->20480
[21:55:29] tag_priority: Priority_08: ->20480
[21:55:29] tag_priority: Priority_09: ->20480
[21:55:29] tag_priority: Priority_10: ->20480
[21:56:00] tag_priority: Priority_02: ->20480
[21:56:20] tag_priority: Priority_02: ->19284
[21:56:40] tag_priority: Priority_03: ->20480
[21:57:05] tag_priority: Priority_05: ->20480
[21:57:25] tag_priority: Priority_05: ->18619
[21:57:45] tag_priority: Priority_06: ->20480
[21:58:05] tag_priority: Priority_06: ->1491
[21:58:25] tag_priority: Priority_06: ->1024
[21:58:51] tag_priority: Priority_02: ->20480
[21:58:51] tag_priority: Priority_03: ->18379
[21:58:51] tag_priority: Priority_05: ->16529
[21:58:51] tag_priority: Priority_06: ->-1
[21:59:16] tag_priority: Priority_03: ->20480
[21:59:16] tag_priority: Priority_05: ->14420
[21:59:41] tag_priority: Priority_05: ->20480
[22:00:06] tag_priority: Priority_06: ->20480
[22:00:26] tag_priority: Priority_06: ->1166
[22:00:46] tag_priority: Priority_01: ->1639
[22:01:11] tag_priority: Priority_01: ->20480
[22:01:11] tag_priority: Priority_02: ->18432
[22:01:11] tag_priority: Priority_03: ->18277
[22:01:11] tag_priority: Priority_05: ->18381
[22:01:11] tag_priority: Priority_06: ->-1
[22:01:31] tag_priority: Priority_01: ->5559
[22:01:51] tag_priority: Priority_02: ->20480
[22:01:51] tag_priority: Priority_03: ->16170
[22:01:51] tag_priority: Priority_05: ->16332
[22:02:16] tag_priority: Priority_03: ->20480
[22:02:16] tag_priority: Priority_05: ->14274
[22:02:41] tag_priority: Priority_05: ->20480
[22:03:06] tag_priority: Priority_06: ->20480
[22:03:26] tag_priority: Priority_06: ->-1
[22:03:46] tag_priority: Priority_01: ->20480
[22:03:51] tag_priority: Priority_06: ->20480
[22:04:21] tag_priority: Priority_06: ->1024
[22:04:46] tag_priority: Priority_06: ->20480
[22:05:16] tag_priority: Priority_03: ->16645
[22:05:16] tag_priority: Priority_06: ->20448
[22:05:41] tag_priority: Priority_03: ->20480
[22:05:41] tag_priority: Priority_05: ->18415
[22:05:41] tag_priority: Priority_06: ->18400
[22:06:06] tag_priority: Priority_05: ->20480
[22:06:06] tag_priority: Priority_06: ->16336
[22:06:31] tag_priority: Priority_06: ->20480
[22:06:31] tag_priority: Priority_09: ->-1
[22:06:36] tag_priority: Priority_09: ->20480
[22:07:01] tag_priority: Priority_07: ->1024
[22:07:06] tag_priority: Priority_07: ->20480
[22:13:27] tag_priority: Priority_01: ->1024
[22:13:32] tag_priority: Priority_01: ->20480
[22:14:43] tag_priority: Priority_01: ->1024
[22:14:48] tag_priority: Priority_01: ->20480
[22:15:49] tag_priority: Priority_03: ->19160
[22:15:49] tag_priority: Priority_09: ->1024
[22:16:14] tag_priority: Priority_03: ->20480
[22:16:14] tag_priority: Priority_05: ->18414
[22:16:14] tag_priority: Priority_06: ->18414
[22:16:14] tag_priority: Priority_09: ->-1
[22:16:39] tag_priority: Priority_05: ->20480
[22:16:39] tag_priority: Priority_06: ->16342
[22:16:59] tag_priority: Priority_03: ->18452
[22:17:19] tag_priority: Priority_06: ->20480
[22:17:44] tag_priority: Priority_09: ->20480
[22:18:14] tag_priority: Priority_09: ->1024
[22:18:39] tag_priority: Priority_03: ->20480
[22:18:39] tag_priority: Priority_05: ->18431
[22:18:39] tag_priority: Priority_06: ->18432
[22:18:39] tag_priority: Priority_09: ->-1
[22:19:04] tag_priority: Priority_05: ->20480
[22:19:04] tag_priority: Priority_06: ->16361
[22:19:29] tag_priority: Priority_06: ->20480
[22:19:54] tag_priority: Priority_09: ->20480
[22:20:24] tag_priority: Priority_03: ->19047
[22:20:24] tag_priority: Priority_09: ->1024
[22:20:49] tag_priority: Priority_03: ->20480
[22:20:49] tag_priority: Priority_05: ->18432
[22:20:49] tag_priority: Priority_06: ->18430
[22:20:49] tag_priority: Priority_09: ->-1
[22:20:54] tag_priority: Priority_09: ->20480
[22:21:14] tag_priority: Priority_05: ->20480
[22:21:14] tag_priority: Priority_06: ->16379
[22:21:39] tag_priority: Priority_06: ->20480
[22:24:30] tag_priority: Priority_03: ->18873
[22:24:55] tag_priority: Priority_03: ->20480
[22:24:55] tag_priority: Priority_05: ->18397
[22:24:55] tag_priority: Priority_06: ->18411
[22:25:20] tag_priority: Priority_05: ->20480
[22:25:20] tag_priority: Priority_06: ->16341
[22:25:45] tag_priority: Priority_06: ->20480
[22:29:06] tag_priority: Priority_03: ->18304
[22:29:31] tag_priority: Priority_03: ->20480
[22:29:31] tag_priority: Priority_05: ->18415
[22:29:31] tag_priority: Priority_06: ->18432
[22:29:56] tag_priority: Priority_05: ->20480
[22:29:56] tag_priority: Priority_06: ->16364
[22:30:16] tag_priority: Priority_03: ->18616
[22:30:36] tag_priority: Priority_06: ->20480
[22:31:06] tag_priority: Priority_03: ->8310
[22:31:26] tag_priority: Priority_03: ->8264
[22:31:46] tag_priority: Priority_01: ->1024
[22:31:51] tag_priority: Priority_01: ->20480
[22:31:51] tag_priority: Priority_03: ->7025
[22:32:11] tag_priority: Priority_03: ->6594
[22:32:36] tag_priority: Priority_03: ->20480
[22:32:36] tag_priority: Priority_05: ->18414
[22:32:36] tag_priority: Priority_06: ->18414

In conclusion, 
At the 20K setting:
- I noticed that torrents in all tags were limited at 20K.  
- The bandwidth order never changed from the initial random order, dictated by seeds, peers, etc.

At the 600K or 20K setting:
- No bandwidth prioritizing proportional with the hierarchical assigned priorities occurred.

[parg]

Here's how the hack currently works (or maybe doesn't...)

First of all the algorithm requires some maximum rate limit to work against - I would suggest something like 80% of your maximum sustainable upload rate provided by your ISP. So my example of 20K is probably nonsense for your setup.

Rate limits for each of your tags with be adjusted between 0 and <max>.

The algorithm then works as follows, checking the state of things every <period> seconds

----

First remove from consideration all tags that are inactive (have no torrents with connected peers) - their limit is set to <max> in the meantime

Next if any of the selected tags are in an 'adjusting' state (have recently had their limit changed) then we exit until next tick

From here on there are two phases that we flip between. Phase 0 is about setting up some stable limits. Phase 1 is about perturbing them to see what happens.

Code:

Phase 0
    for each active tag T
        if
            T is achieving a stable rate equal to its limit 
        then
            things look good
        else
             reduce the limit of T to the rate that it is currently achieving
        endif
    endfor

    if
        things look good for all of the tags (i.e. we didn't reduce any limits)
    then
        goto phase 1
    else
        stick in phase 0
    endif

Phase 1
    for each active tag T
        if 
            T's limit isn't currently max
        then
            Set T's limit to max and reduce each lower priority tag's limit by 2k/sec

            Wait until things are stable again and then set T's limit to whatever has been achieved and move onto the next tag
        endif
    endfor

    if 
        no adjustments have been made
    then
        goto phase 0
    else
        stick in phase 1
    endif

So the overall idea is that we get achieved rates set for all tags. Then we periodically work through the tags from high->low priority, setting their limit to max and decreasing the limits of all lower tags slightly to try and push bandwidth from the lower priority tags to the higher priority one. Once things have had time to adjust we set that tag's limit to what has been achieved and move onto the next priority tag.

Feel free to check the code in the Prioritiser class at the bottom of

https://svn.vuze.com/public/client/trunk...ndler.java

and suggest improvements/fixes.

I tested it with 3 tags and prioritising download traffic rather than upload, and it seemed to basically work.

[ccrisvuze]

1.  <<First of all the algorithm requires some maximum rate limit to work against - I would suggest something like 80% of your maximum sustainable upload rate provided by your ISP.>>
Say I want to set that at 800K.
Where does this routine pull this number from?  
Do I set this in Tools>Options>Transfer>KB/s global max upload speed> set to 800?

2.  In the expression:

Code:

priority_up/down [<num>=<tagname>,]+freq=<freq>,max=<rate>

and refering to what you wrote:
<<Rate limits for each of your tags with be adjusted between 0 and <max>.>>
this would indicate that I sould set max=800K
Correct?
I should expect to see the low priority torrents start at a high (max-800) value but drop significantly in time.
If I am wrong and there is a more sensible value for <max>, please let me know.

3.  As far as syntax, is the statement below correct?

Code:

enable=yes
priority_up 1=Priority_01,2=Priority_02,3=Priority_03,4=Priority_04,5=Priority_05,6=Priority_06,7=Priority_07,8=Priority_08,9=Priority_09,10=Priority_10,freq=5,max=800K

If it is incorrect, please let me know.

I will test again on B04 as soon as you confirm the above.  Thanks. 

[parg]

You don't need to set any maximum within Vuze itself (i.e. no need to go to Tools->Options->Transfer and set anything there).

If you do have any other limits set then make sure they aren't < 800k as that might interfere with things though.

It might be worth testing with less priority levels as it might be more obvious what's going on.

What you should see is an initial settling period during which limits are somewhat random. This should then transform into a set of limits on the tags with higher limits on the higher priority tags.

For things to settle correctly you need to have torrents that can achieve fairly stable upload rates though.

[parg]

I've fixed a bug and improved the logging somewhat for B05 - might be worth waiting until this is built later today

[ccrisvuze]

Currently testing, at the 1 hour mark now.  Took some screenshots. 

After program settled, before invoking prioritizing.
[Image: 3mXHw8B.jpg]
[Image: RK5wPwC.jpg]

Invoke prioritizing.
At the 10-minute mark
[Image: h3VCYKO.jpg]
[Image: 9UPZ12G.jpg]

At the 20-minute mark
[Image: KtFlaC6.jpg]
[Image: K2RDmPl.jpg]

At the 35-minute mark
[Image: RaFLnbL.jpg]
[Image: XpnCiwK.jpg]

I will try B05 as well later.

[parg]

But your achieved upload limit is only around 400KB/sec, with a maximum of 800KB/sec, so why would you expect any kind of prioritisation to be applied at all? It isn't needed, you have spare upload bandwidth.

The aim of the prioritisation algorithm is to move available upload bandwidth from low priority tags to high priority tags *when bandwidth is being restricted*

If your 'priority 1' torrents can only seed at 1K/sec then they will end up with a limit of 1K/sec.

[ccrisvuze]

The remaining bandwidth is being used up by other processes I must run at work.  Of course, to facilitate testing, I could temporarily shot down work.  However, a realistic scenario includes some competition for bandwidth between VUZE (torrenting) and my work.  I could also set the "max" value to 400 (and set a global limit for VUZE), but the use for work varies all the time (from 0 to a few hundred MB/sec) and setting a global limit of 400 for VUZE would underutilize my connection.

I looked at the code and at the results so far.
I understand parts of the algorithm (and code).

The <freq> is now set at 5 seconds. 
If I understand correctly, the routine (phase 0 and phase 1) cycles once every 5 seconds through all priority tags (in my case, 10).
The routine finds the next non-max tag, sets to max and limits the others to achieved rate.
I don't understand how this would favor high priority tags.  It seems every 5 seconds every tag has an equal opportunity of becoming set to max (while the other tags are reduced to achieved rate). 

I did not figure out what mechanism introduces a bias: what gives bandwidth preference to the tags at the beginning of the cycle (high priority torrents) and conversely removes bandwidth at the end of the cycle (low priority torrents).