Jump to content

Does 'Priority' setting affect download thruput?


kj2141

Recommended Posts

Posted

When downloading "multi movie" torrents (like a season of tv series or trilogy/quadrilogy) what is the impact on overall thruput (not specifically download 'speed' in mbps) of specifying a download priority other than Normal? How about for the case of Skip Download?

Specifically, if i Skip Download is the file downloaded to my client and THEN discarded - OR is that file of the torrent simply never downloaded to me at all (and only the request to the seeder was wasted)?

And if i set Priority High (say for the first of a quadrilogy) does that impact the total thruput of downloads for the full quadrilogy or not (i.e. am i doing "extra work" to download when i have one file set to High Pri and others set to Normal Pri)? OR is there some kind of mechanism in the client request that is sent to seeders that says "if possible give me the high priority stuff but otherwise give me anything you have" so that the action with the remote seeder is not "wasted"?

I am on a rather slow broadband (Southern Leyte in the Philippines) so i cant really "afford" to waste bandwidth either downloading stuff i deem unnecessary (i.e. it is downloaded and then discarded on my end) NOR can do i want to send a request to a seeder for something that he simply doesnt send back (i.e. because i said High Pri and he doesnt have that portion of the torrent so he sends nothing instead of sending some other part of the torrent).

Hope my question was clear -- and hoping for answer(s) that are factual rather than "assumptions"!

Thanks, kj

Posted

I am assuming that you talking about setting priority of the individual files within a torrent? By setting a file to high priority you asking it to try to prioritize and finish that file first. If all the files have equal # of source then it will finish that file first. The other files in normal or low priority would still get their parts downloaded but at lower priority or if the parts for the higher priority files are not around. You can always manually tell it to only download that one file you like first by set do not download on all the other files. This would be the quickest way to finish that one file you like first but it might not give you the fastest time to complete the whole torrent for obvious reasons.

When you initially start a torrent, it attempts to allocate space to all the files in the torrent and start all files so you need to set your file priority early on. If you don't want it to download a file, and didn't tell it in time to not download that file, you will have to go back and delete that incomplete file after setting it to do not download that file..

Hope that helps with your questions..

Posted

"Skip download" may/will still download all or part of the file, as the torrent protocol has no concept of 'files' per se, it only 'knows' about blocks of data, (the pieces) and a "file" may be fragmented across one or more pieces, so the client does need to download all pieces that make up a particular 'file' from your perspective, and in doing so may download all or part of a file you have 'skipped'

The priority sets the order of which pieces that contain the data for that file will be requested. A 'seed' is a peer that has ALL the blocks of data so a request to a seed WILL return something, unless your client is "choked" or banned by a peer client. The only time a request will be "wasted" is when the peer has no available slots for your request and at that point your client will be 'choked'.

Posted

Thanks .... so if i understand properly .... in the 'skip file' context i may get a "the first part of a piece" but presumably not the remaining "parts" of the same piece (assuming the actual amount of data transmitted in a comms packet is just a small "part" of a torrent "piece")? In which case, the percentage of potentially "wasted" bandwidth is rather limited to (most of the time) just the first "part/packet" of a torrent piece, or not too much in the scheme of life????? In other words, some but not a lot of overhead.

Whereas for a "Priority" setting, there appears to be little (if any) "wasted" bandwidth as [guessing here] the client on my end is able to request the pieces in "priority order" from the seeders (or other peers, to the extent another peer might have the requested piece)???? In other words, not very much overhead at all.

Unless i grossly misinterpreted your good response .. thanks

kj

Posted

The protocol is very efficient and yes, very little is wasted in overhead, some is unavoidable especially when there are HTTP trackers for a torrent, as HTTP is a higher 'cost' protocol than UDP is, and "cost" in networking refers to time rather than monetary concerns.

Posted

OK ciaobaby, you've got my curiosity up a bit! If i can impose a bit more on your knowledge base, maybe you can confirm or correct my speculation about "how it works". I fully get the whole p2p thing and the concepts behind it ... but i have a question about the mechanics of it. Specifically, I get that there are no "files" in a torrent file, only lots of "pieces" that are [i assume] somehow indexed such that each "logical file/movie" has its starting piece # identified in some manner. But how are "requests" for pieces from many seeds/piers actually set up and sent out? For example, it would presumably be a big waste for the client to "broadcast" that it wants"any piece" because of the potential for both duplicates and also "nobody sending piece #xxx" - so .... can i assume that there is some kind of mechanism that when a pier is identified in my client that somehow (maybe a big bit map??) it informs my client "which pieces" it has available and then my client makes specific requests to each of its peers for a specific piece that peer has announced it has (since seeds have by definition 100% of the file i guess there is no need for this detail)???? If not something like this, then how does my client (or the responding peer) know "which piece or pieces" to transfer??? AND since a "piece" is much larger than a TCP packet, i assume there is some mechanism to insure that 1) a piece is actually complete in the peer before it says it is available and 2) my client somehow "collects" the "packets" into a final "complete piece" before it declares that piece "received" by my client????

I know this is not part of my original question, but if you feel inclined to further the education of a relative newbie to this whole torrenting thing, i would enjoy learning.

Thanks,

kj

Posted

It's a bit like a jigsaw puzzle, but instead of a picture to work from all the pieces are numbered and the client has a 'map' of where all the pieces fit into each other (the metadata) so the hexadecimal codes that tells the disk filing system where all the parts of the file are and what the file is all go back in the right order. On the disk all the parts of the file may not be in contiguous clusters anyway but provided the bytes all go back in the same order it will work.

Files are merely chunks of data that is a certain size and in a certain order, so provided a chunk of suitably sized disk space is allocated to a file by the client and the OS it does not really matter in what order the block are assembled just as long as they are in the right order.

I suppose tiling a wall or a floor would be the best analogy. Lets say that each tile is EXACTLY 'N' long and there are 100 tiles in the row, you could start with tile 65 provided the leading edge of the tile was placed at 64N from the start, you could then place tile 64 or 66 next to 65 OR you could get tile 26 and place it at 25N. In computer programming parlance it is called offset addressing and offsets start at zero (0) not 1.

If you open the "Pieces" tab in the "Detailed info" panel of the downloading torrent you can watch the progress of the blocks and pieces that make up each block as they are coming in and get some idea of what goes on.

To "decide" which pieces to get first the client uses the "least cost" method and download the quickest ones, each piece is 'hash checked' against a checksum (Hashing) in the meta data to verify it is valid and no corruption has occurred during transport.

A sort of BitTorrent in a nutshell :) Not sure whether Bram Cohen would agree with my analogies or not but hey! :D

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...