Download from users in same country = better speed...

[hace]

Why not make µTorrent prioritize seeds and peers from your own country (if available) so in that way you get better up and down speeds, what do you think? Maybe even prioritize those with same internet supplier???

[ScubaSteve]

someone has already requested a TTL type feature. dont think its going to be implemented though as its abit unfair on 56k users.

[chaosblade]

Why would that give you better speed ? If you're in a country that mostly has dial up users, wont that decrease your speed ?

I dont think that it would at all, and favoring peers for no good reason is bad in the first place.

[ Disclaimer For Problematic People: This post suggests my opinion on the matters of this Thread. If you have a serious issue with accepting other people's opinions, Please disregard this thread. Thank you. ]

[Keilaron]

I thought it was fairly well-known that the closer someone is, the faster the communication goes with someone.

That's why mirror lists often indicate where the mirror is, no? Y'know, so you can pick (if you're in Canada, for example) a mirror in Canada rather than, say, one in Japan.

And I've tested something interesting (but probably rare in terms of BT) - if my data never leaves my ISP's "domain", I get much better speeds. I have a friend who lives not too far away and that has the same ISP as me: we get better speeds to each-other than anywhere else. (But that way just be because we don't get deprioritised since we're not leaving the ISP's "domain" )

Oh, and of course, if implemented, this should be user-selectable, in case of the dial-up issue mentioned above.

[r00ted]

I think it would be better to prioritize by speed (but that's another suggestion/thread).

There may be circumstances, where you wouldn't want to connect to people in your same country.

[Liquido]

ISP;s would prolly be glad if torrent clients prioritized other peers from the same ISP.

/Liquido

[Indie]

ISP;s would prolly be glad if torrent clients prioritized other peers from the same ISP.

/Liquido

Seriously do you really think they give a damn about that?

Anyways this would be a really nice feature and I don't see how anyone would suffer from it (not even 56k users).

[knotty]

Don't know why you think that would be a good idea ,there aren't many got better up than 32 k in the U.K ,if you only connect to them it would slow torrents down .I used to get 200k + alone from the boss of another site ,he wasn't based in the U.K either .And that was when he was seeding to several others as well .

[tumu]

My original request about TTL feature contains the basic idea: http://forum.utorrent.com/viewtopic.php?t=907

Why local networks are always faster than remote ones? It is because the close proximity of users allows faster speeds in networking equipment without reliability issues. This even applies to network links inside countries. ISP's can arrange to peer with each other in the most optimal places to allow fastest speeds between the networks. Network links to foreign countries are subject to problems from distances, costs, peering locations, uncertain reliability and congestion, which all have bad effect to speed.

And regarding the peer favoring, all the current clients, including uTorrent, randomly try to find the peers it can upload fastest to (which may or may not get fastest download). Notice the keyword RANDOMLY. It has no idea which peers are going to be the fastest until it tries them all. This random choosing takes time and is the reason why torrents start up so slowly. The TTL priorization would narrow the initial set of peers to the closest ones first, in where one is more likely to find a fast upload peer from. After that narrowing, you either get benefits or you are forced to wait for the random selection to do its work.

Also please do not compare seeding clients speeds to unfinished peer speeds. You have no control over seeds. They will randomly find the fastest peers they can upload to and you can't influence that by uploading (as they're complete). All you can do is wait to be picked and hope that the seed can upload to you faster than its existing peers. With unfinished peers, your upload makes them to give you a upload slot eventually (sooner than the random selection).

[sethg]

Actually, the BT protocol has you randomly select one choked peer at a time to optimistically unchoke, upload as much as we can, then see how much they send back to us. We then rank the downloading peers (not seeds) in order of download speed and choke the slowest one. This algorithm finds the fastest downloaders given the amount of upload bandwidth we have and how well we use it. It does not select the peers who can accept our uploads the fastest, except in seeding mode.

Thus, it will automatically find the peers who will give us the best service, regardless of what country they are in. Local peers are only faster if everyone had the same speed network connection, used the same network equipment, ran the same number of concurrent torrents and set their bandwidth limits the same. The latency might be higher for hosts further away, but with reasonable packet sizes, throughput would not be greatly affected. The other factors listed greatly overshadow the effects of latency.

[tumu]

You make interesting points, I was trying to explain myself without going too technical on details. Lets speculate a bit if you don't mind?

I don't know about all clients behaviour, but most I've seen to act as follows:

1. When you start a torrent, you get a peer list from tracker

2. They fill all upload slots either in order from the peer list or in random order.

3. Upload commences and optimistic unchoke begins to find faster peers (one at a time)

(Note that I assume you have pieces to share, starting without pieces will delay the 3rd item until a optimistic seed or peer sends full piece to share.)

This sequence means that unless you get very lucky or the tracker gives you optimal set of peers (yeah right), you most likely end up with suboptimal peers and have to wait for the optimistic unchoke to find faster ones. This search takes time. TTL feat would reduce the initial set from tracker to ones which are likely to be fast from the start.

Now if it happens that the remote networks are congested, you waste lot of time to measure the speed of remote peers. If remote networks are traffic shaped/limited, it is useless to measure their speed first. And as faster network technologies in use on long network links like to buffer data into larger packets for easier congestion control, optimistic unchoke can measure the buffering speed than the real long term transfer speed which is subject to congestion control with large packet loss.

[slimy]

it should be an option and by continent seems more feasible to me as certain countries don't use bittorent much and that would be pointless for many.

[sethg]

I can tell you what I have observed, so far. I happen to live in the Mid-Western U.S. I am a few hours driving distance from Chicago, and that's where all of our local fiber connections go through, but I rarely find a good peer in Chicago. Instead, it is often someone on a much faster cable or DSL connection in Canada, Netherlands or Scandanavia, many thousands of kilometers away. Sometimes it is someone using a University account with a _lot_ of bandwidth, but it is rarely local and just as often outside the U.S. as inside it. Those are just personal observations, they don't prove anything.

It's important in communications to separate the effects of latency and throughput. When data packets are large, assuming that each data packet has to be acknowledged before the sequence can continue, the latency would have to get pretty bad before it would noticeably affect the throughput. We define throughput as the average number of payload bytes delivered per second. If we allow something called pipelining, where a host will send the next data packet before receiving acknowledgement for the first one, then latency has almost no affect on throughput. There is no reason to limit the pipeline to two packets. If there is a bad packet, the recipient can request retransmission later.

The TCP protocol used by BitTorrent is built to handle packets sent out of order and retransmission of bad packets at a later time without causing major problems. It's a bit like the old modem protocols Kermit and X-modem where you had the notion of a sliding window where the sender could get ahead of the recipient. They managed to keep the data flowing steadily even if the delay from one end to the other was quite large.

Thus, I would agree with other posters who have said that selecting peers geographically is not in your best interest as a downloader. I would go one step further in saying that selecting peers based on anything other than their download rate to you is not in your best interest as a downloader. I suggest that you download a number of torrents, some large and some small, and see who gave you the most data at the end. I bet they won't all be local. If this is true, and you had restricted yourself to local peers, you would have had a slower download. Even if you had tried local peers first, it would have taken you longer to find those faster non-local peers. I don't believe there is any way to tell ahead of time who will be your fastest peers and the random experiment used by the BT protocol is the fastest way.

You also mentioned the effect of packet coalescing and buffering on long lines. In my experience, that doesn't happen much. You actually tend to see fragmentation more often than coalescing. However, you are right that some elastic buffering occurs. Since the optimisitic unchoke period is 30 seconds, this is plenty of time to get a reasonable estimate of someones sustained download rate to you. No major nodes on the internet have buffers large enough to hold more than a fraction of a second worth of data. It is also plenty of time for someone's TCP stack to fully ramp up to steady state.

Just my two cents worth.