Transfer Queue Management

Transfer Queue Management is a combination of two systems. Seed queue management, which cycles seeds in and out of the standby queue to maximize usefulness of outgoing bandwidth, and download queue auto-skip, which will start queued downloads when your bandwidth is not being fully utilized.

These two systems can be individually disabled in the Settings > Transfers > General section, using the checkboxes next to "Auto-manage slots". Advanced users can also adjust these systems by clicking the "Details" button, which will allow editing of an XMLe file that controls several aspects of operation.

Seed Queue Management

Dead Seeds

Seeds that are running (not in standby) but have no activity are classified as dead. The criteria for being dead is controlled by the deadseedqualify tag.

<deadseedqualify 
windowdur=160     //look at each seed's bandwidth going back this many seconds
windowtaperdur=20   //and this many additional seconds with a weight tapering to zero
avgdur=8     //average speed must be maintained over this many seconds
maxspeed=1000      //average speed below this qualifies as dead
/>

The seed's outgoing file bytes bandwidth history (which is recorded every second) is used as the main deciding factor.

The attribute windowdur controls how many seconds into the past the history will be examined. The windowtaperdur adds additional seconds, but these are factored with a weight that linearly tapers from 100% to 0% (you can just use 0 or a relatively short number).

The attribute avgdur and maxspeed set the bandwidth threshold, which if not crossed at any point during the examination window will cause this seed to be in the dead list.

Dead seeds do not count in the "Seeding" total that is continiously displayed at the bottom of the main Tixati window.

Slots

There are 3 types of slots. Permanent, temporary, and dead.

Permanent slots are the ones you specify in Settings > Transfers > General. This never changes. These are consumed by the most "worthy" transfers, as determined below.

Temporary slots are extra slots the system can use to run a few extra seeds to measure their seed/peer counts and see how much actual file bandwidth will be used. If the number of active, non-dead transfers exceeds the number of permanent+temporary slots at any time, transfers will be "pushed" to standby, using the parameters in the seedstandby tag (described below) to decide which ones are pushed first.

Dead slots are used by any transfer that has qualified as dead as described above, however dead transfers can use temporary or permanent slots too if those slots are not being used otherwise, and if the dead transfer has been seeding for less that a certain amount of time, determined by the minpushage attribute of the deadseedstandby tag (described below).

The number of temporary and dead slots available is determined by the seedslots tag.

<seedslots 
temp=[4000 2 8]   //max temporary slots for periodic updating of seed/peer status, can be plain integer or [ *ulslots/1000 min max ]
dead=auto    //max slots reserved for monitoring dead seeds, can be auto, integer, or [ *ulslots/1000 min max ]
/>

Either of these attributes can directly specify a raw integer. You can also specifiy that these numbers should be calculated based off the user-configured number of permanent upload slots by specifying three integers within square brackets. The first number will be multiplied by the number of permanent slots, then divided by 1000, which allows you to specify a factor in tenths of a percent. The second and third number specify a min-max range that this result will be limited to.

The number of dead slots can also be specified to be auto, which is the default and will use a more advanced algorithm that takes into account other factors.

Seed Cycle

On regular intervals, the seed cycle will possibly move running seeds into standby, and/or start standby seeds. The decision of which seeds to start/stop is made using the recently connected seed/peer counts (which are in brackets in the status column) and how many seconds they have been seeding or in the standby queue.

The interval of the seed cycle is determined by the seedcycle tag.

<seedcycle 
interval=25    //only cycle seeds in/out of standby queue this often
startupwait=180    //don't cycle seeds until it has been this many seconds since startup or offline state (no dht traffic for 20 sec)
/>

The interval attribute specifies the number of seconds between cycles. The startupwait attribute specifies the minimum number of seconds Tixati been running and connected to the internet (determined by DHT activity) before a seed cycle can happen. If the internet is disconnected by more than 30 seconds, the startup wait must happen again before any seed cycles.

The seedstandby tag has attributes which are used to figure out which seed(s) will be sent to standby, if any. Seeds are only cycled to standby if there are more active (non-dead) seeds than permanent slots. A seed must have been running for a minimum number of seconds to be cycled, specified by the mincycleage attribute. If there are more active seeds than perm+temp slots, then seeds will be "pushed" into standby, using the same criteria to decide which ones, except the minimum number of seconds running is determined by the minpushage attribute, and this minimum can also be lowered dynamically if needed to find enough seeds to push.

The keepchancetable is a three-dimensional nested set of maps that is used to make a score for each seed, based upon it's number of seeds, number of peers, and time since the seed was last started. These scores are then multiplied by a random number * 700 + 100 before being ranked. The seeds with the lowest scores are most likely to be sent to standby.

The deadseedstandby tag is much the same, except that it is used to manage the "dead" slots, which are also cycled on the same interval. Dead seeds may also be randomly sent to standby if there are more dead+active seeds than perm+temp slots, the odds of which are determined by the randstandbychancetable.

Seeds are started from standby during the cycle if there are any free temporary slots. The seedstart tag contains three tables which are used to choose which standby seeds to start based upon the most recent connected seed/peer counts, and how many seconds since the seed was last running. The startchancetable is used when we already have enough active seeds to fill all the permanent slots and are just trying to fill temporary slots. The desperatestartchancetable is used when we have at least half the permanent slots filled, otherwise the vdesperatestartchancetable is used.

Download Automatic Skip Queue

This feature will automatically start a limited number of queued downloads (beyond the number of slots specified in Settings > Transfers > General) if bandwidth is not being fully utilized. It is controlled by the downloadautoskipqueue tag.

<downloadautoskipqueue
maxextraslots=[2500 8 40]    //max extra download slots, can be a plain integer, or [ *dlslots/1000 min max ]
windowdur=170    //look at bandwidth going back this many seconds
windowtaperdur=10    //and this many additional seconds with a weight tapering to zero
avgdur=25    //average speed must be maintained over this many seconds
minratefactor=700    //no action unless average speed is lower than throttle * this number / 1000
startwait=120     //no action until it's been this many seconds since a download started running (not queued)
stopwait=45      //no action until it's been this many seconds since a running download was re-queued or stopped
startupwait=180    //no action until it's been this many seconds since program startup or offline state (no dht traffic for 20 sec)
/>

The main bandwidth history and throttle is used to decide if a new download should be started from the queue.

The attribute windowdur controls how many seconds into the past the history will be examined. The windowtaperdur adds additional seconds, but these are factored with a weight that linearly tapers from 100% to 0% (you can just use 0 or a relatively short number).

The attribute avgdur and maxspeed set the bandwidth threshold, which if not crossed at any point during the examination window will cause the system to try starting another queued download.

The startwait and stopwait attributes are in seconds and are used to stop downloads from being started if there has been recent stop/start activity, so that things have a chance to stabilize. The startupwait attribute specifies a minimum duration in seconds since Tixati was last started and/or went online (as determined from DHT traffic).