NS BitTorrent - what is it good for?
Posted: Fri Nov 28, 2003 7:32 am
(Didn't want to spam up the announce thread, and this seemed to be the most appropriate private forum)
Anach_Server said:
I do agree that splitting your bandwidth is unwise, at the moment I have a 5/4/3 split between DC/external p2p/BT (no-one is using BT, or I would reserve more). Agreed, that is 3k which is currently unused, and wasted. Splitting your bandwidth between networks also slows down file replication.
However, in that case that BT was being used - I do not think you would see 'dozens' of torrents being hosted by clients.
I think that there will always be a place for DC - the nature of DC and BT is different. I am currently sharing thousands of files on DC. This is near-impossible on BT, and insanely impractical to do on that system. As you can see on the NSBT page, the shares are a few large and popular files.
To address your concerns on incomplete downloads, with a close community such as we have, I see no problems with requesting a reseed of a popular file. I would like to think that all seeders would stay online until the last download is complete, but in the case you mention, I am sure someone would re-seed on request (I would
).
The power of BT is in multiple sourced peers. I did a test the other night. Downloaded a 400Mb file in less than 7 hours (3 peers) averaging 10k down. On DC, this would have taken me about a week (to get a slot if I didn't beg) and another 2 days to download (assuming no disconnections) at 3k.
To contrast with an actual practical example: I have 100Mb queued up in DC atm, and have had this queued for about two weeks. Searches for files I want regularly turn up only a couple of sources... in a network of 60 clients.
I don't think I'm following Anach's bandwidth calculation correctly, but if he was seeding a file to a 5 BT client network, and the 4 other users were getting 1.2kb each from him, (assume each sharing 5k, multiple files) the theoretical maximum client download would be 1.2+(3x5)=16.2k/sec. This is a best case scenario and unlikely to occur for any extended period of time, but I would be more than happy to be one of those clients.
The maths for multiple downloads are too tricky for me but if we assume (for simplicity) 2 downloads per client, equal bandwidth usage, the individual download drops to 1.2+(3x5)/2=8.7 (on the file you are sharing), and 3x5/2=7.5kb/sec on the other one I would disagree that this is not worth doing, and that DC would be a better medium for transmission. At least everyone is actually getting something at the same time. In the end, regardless of the client type, DC or BT, every client is sharing the same amount.
Anach's example also avoids one of the prime features of BT, and biases the argument toward DC in that it deals with a tiny group size. Naturally, with a group of only 5 clients, BT suffers by comparison, and DC can be seen as more worthwhile, with more features (lists, chat, etc) but if you were to apply the scenario to real world situation, you would find it changes dramatically. I leave the 'best case' download calculation of our network of 60 users each sharing 5k on one download as an exercise for the reader.
The thing that is really good with BT, is by it's very nature, you share while downloading. This means higher aggregate downloads and faster replication through the network. Personally, I have upped unique files two or more times to the hub (and watched others do so also), and they are just not getting distributed. When it takes a couple of days to upload an image and then the person burns and deletes it without sharing.... that's pretty sad.
...and I don't want to hear ppl crying about 'no hdd space'. Drives are cheaper than ever now. I have a 30Gb system drive and a 6Gb server. Everyone can find a few Gb to share, I am sure.
My two maxims are:
"If it's worth downloading, then it's worth sharing" and
"Upload every download at least twice."
I think a number of people could learn from those.
So what we have is a system where it takes a long time to replicate once to the next client, then again to the next, and so on, whereas BT spreads the file to all clients requesting it simultaneously.
I really think BT is the future for large, unique, file replication in the shortest time. DC will always be there, but BT whips it for speed on popular files.
Personally, I think I will always be on DC, but atm I am more interested in BT, and when the community grows, I will give it the major share of my bandwidth.
*me reviews post*
Woah, an essay! All IMHO and meant in the spirit of debate and discussion, of course.
Anach_Server said:
Sorry dude, but i cant see this working
for one, I cant use it and my other download programs at once, i just dont have the bandwidth.
Especially to leave them open.
Secondly, I cant see me or anyone else leaving dozens of torrents open for very long. What happens after a reboot?
You download a file, dont get it all, what happens if no one hosts it, its a waste of a download.
I might as well just get off DC and at least i can get it this week, next week or the week after, without worrying.
Also. most people still want the hub open, so to have bandwidth for both, most people only have 10k upstream. say 5k for hub and 5k for BT.
So you have 5 people, all sharing 5k -10 total upstream to several BT files. This allows me to share a 5 source BT and get it from 4 others all getting 1.2 k each. But if they are upping another BT to someone else, that is halved again. I might as well just get it from DC.
Or am i seeing this wrong?
I do agree that splitting your bandwidth is unwise, at the moment I have a 5/4/3 split between DC/external p2p/BT (no-one is using BT, or I would reserve more). Agreed, that is 3k which is currently unused, and wasted. Splitting your bandwidth between networks also slows down file replication.
However, in that case that BT was being used - I do not think you would see 'dozens' of torrents being hosted by clients.
I think that there will always be a place for DC - the nature of DC and BT is different. I am currently sharing thousands of files on DC. This is near-impossible on BT, and insanely impractical to do on that system. As you can see on the NSBT page, the shares are a few large and popular files.
To address your concerns on incomplete downloads, with a close community such as we have, I see no problems with requesting a reseed of a popular file. I would like to think that all seeders would stay online until the last download is complete, but in the case you mention, I am sure someone would re-seed on request (I would
).
The power of BT is in multiple sourced peers. I did a test the other night. Downloaded a 400Mb file in less than 7 hours (3 peers) averaging 10k down. On DC, this would have taken me about a week (to get a slot if I didn't beg) and another 2 days to download (assuming no disconnections) at 3k.
To contrast with an actual practical example: I have 100Mb queued up in DC atm, and have had this queued for about two weeks. Searches for files I want regularly turn up only a couple of sources... in a network of 60 clients.
I don't think I'm following Anach's bandwidth calculation correctly, but if he was seeding a file to a 5 BT client network, and the 4 other users were getting 1.2kb each from him, (assume each sharing 5k, multiple files) the theoretical maximum client download would be 1.2+(3x5)=16.2k/sec. This is a best case scenario and unlikely to occur for any extended period of time, but I would be more than happy to be one of those clients.
The maths for multiple downloads are too tricky for me but if we assume (for simplicity) 2 downloads per client, equal bandwidth usage, the individual download drops to 1.2+(3x5)/2=8.7 (on the file you are sharing), and 3x5/2=7.5kb/sec on the other one I would disagree that this is not worth doing, and that DC would be a better medium for transmission. At least everyone is actually getting something at the same time. In the end, regardless of the client type, DC or BT, every client is sharing the same amount.
Anach's example also avoids one of the prime features of BT, and biases the argument toward DC in that it deals with a tiny group size. Naturally, with a group of only 5 clients, BT suffers by comparison, and DC can be seen as more worthwhile, with more features (lists, chat, etc) but if you were to apply the scenario to real world situation, you would find it changes dramatically. I leave the 'best case' download calculation of our network of 60 users each sharing 5k on one download as an exercise for the reader.
The thing that is really good with BT, is by it's very nature, you share while downloading. This means higher aggregate downloads and faster replication through the network. Personally, I have upped unique files two or more times to the hub (and watched others do so also), and they are just not getting distributed. When it takes a couple of days to upload an image and then the person burns and deletes it without sharing.... that's pretty sad.
...and I don't want to hear ppl crying about 'no hdd space'. Drives are cheaper than ever now. I have a 30Gb system drive and a 6Gb server. Everyone can find a few Gb to share, I am sure.
My two maxims are:
"If it's worth downloading, then it's worth sharing" and
"Upload every download at least twice."
I think a number of people could learn from those.
So what we have is a system where it takes a long time to replicate once to the next client, then again to the next, and so on, whereas BT spreads the file to all clients requesting it simultaneously.
I really think BT is the future for large, unique, file replication in the shortest time. DC will always be there, but BT whips it for speed on popular files.
Personally, I think I will always be on DC, but atm I am more interested in BT, and when the community grows, I will give it the major share of my bandwidth.
*me reviews post*
Woah, an essay! All IMHO and meant in the spirit of debate and discussion, of course.