Bitcomet reports odd upload speeds

BitComet BitComet General Discussion
1

I have a DSL connection 4Mbps/384kbps. Now, since I’ve installed v1.14 of Bitcomet I’ve seen some odd upload speeds displayed by Bitcomet. As you know (those who have installed it) v1.14 allows you to set different upload limitations for the case when you’re downloading and for the case you’re just seeding. So I’ve set the later to “unlimited” and, having just seeded some torrents for two days now, Bitcomet is steadily reporting an average 125KBps upload speed (with variations between 116KBps - 132KBps). This struck me as odd, since this would mean that I’m uploading at 1Mbps (almost 3 times more than my advertised speed). Now, I know that my ISP recently added to their internet offer an 12Mbps/1Mbps option, but I haven’t upgraded to that and all the other connection types in their offer have 384 or 256 upload speeds adevertised. I even checked my account info on their web page and it doesn’t say anything has changed.

So I’ve closed Bitcomet and all the other internet connected applications and ran some speed tests (many, actually) on various sites all around the globe (North America, Europe, Asia, Australia) to get an idea of my up/down speeds and the biggest upload speed I’ve got reported was up to over 400kbps ocasionally, but mostly in 300 - 370kbps, therefore pretty much in my advertised range.

Nevertheless since I’ve started Bitcomet again, running solely the same upload tasks, I read the same uploade speeds (around 120 -130KBps). Which is great by the way, only if it were real. I don’t have detailed technical knowledge of the way DSL works, so I can’t figure out if this is really possible.

Does anybody have a clue as to how this could be possible? (Or has the Christmas come early this year? :smiley: )

P.S. Oh, and by the way, the biggest part of this upload speed belongs to LT seeding (about 94KBps-105KBps) which is set to “Auto”.

OS: WinXP

Connection: wireless to a wireless DSL router and then further by DSL.

2

It depends specifically on your connection details, but the basis is, “what can we be sued for?”, The contractual speed is therefore the minimum, in most cases - what you’re assured that you’ll get. If you happen to get more at the moment, great, but they’re not obligated to keep supplying that.

In some situations you might get much more. This is common for cable subscribers if the service is new. Bandwidth for the junction is allocated for the traffic that the company eventually expects, but meanwhile subscribers may get really huge upstream bandwidth from it until more people in the neighborhood subscribe.

Now that the phone company can play in the CATV sandbox, this seems to happen with ADSL too, but it’s probably more of a screwup than anything planned.

3

Well, this would be great if this really is the case with my connection. In fact, that’s what I’m really trying to determine. I mean, how come that it’s just Bitcomet that’s reporting this, whereas all the other speed tests I’ve run stick to the advertised speed.

At this point two scenarios come to my mind: either there is some glitch to the way Bitcomet is reporting my upload speeds or there is some loose end on my ISP’s side, as you said, of which bittorrent protocol takes advantage (I don’t know how though, I guess by having so many connections at a time or something) in order to achieve such high speeds. Because as far as I’ve seen I get this high speeds only with Bitcomet.

But I just can’t figure a way to tell for sure which is the true one.

4

You should keep in mind that other applications don’t send much upstream. A web browser, for example, just sends a short url, which is not supposed to be longer than 256 characters. It hardly gets started before it’s finished.

In return, it gets back an entire web page, with graphics, layout and scripts.

A bittorrent client, otoh, sends a LOT of data upstream, and grabs all of that limited bandwidth that it’s allowed to. They will crowd everything else off the network if not restrained. (This is part of why public access ports generally disallow P2P.)

It is possible to throttle a connection, but it actually requires that somebody go out to each house and install a choke on the line, so it’s labor-intensive. It’s usually just not necessary to do that, and most providers don’t.

5

Well, what I was meaning when I said that I get this high speeds only in Bitcomet was as compared to the speed tests I’ve ran. As you know these tests usually run by downloading a piece of data on your computer and then uploading it back in order to determine the up and down speed of your connection. Some of them even allow you to choose the size of data chunk and I usually chose the bigger ones in order to get closer to a sustained transfer rate. Nevertheless they don’t exceed my advertised speed. OTOH Bitcomet does it constantly.

Now, what comes to mind is this: HTTP or FTP transfers (because I’m guessing this is the transfer protocol these sites use for testing) don’t work by opening (not by far) as many connections as Bitcomet for one transfer, no matter what direction. So maybe this feature in the bitttorent protocol (or another one that I don’t know about) finds a way around the control software of my ISP in order to achieve this high speeds (that is, as I said, if the speeds Bitcomet displays to me are real).

I wish there was a way I could verify this. Is there any way I could transfer this seeding tasks to another bittorrent client in order to test if I get upload speeds any close to this?

6

Taking your last question at face value, yes, you can transfer pretty much any task from one client to another in mid-task. As an example,

Stop the BC task

(For downloads, not seeds)If you have used the incomplete-extension option, remove the added extensions from all relevant downloads

Start µtorrent.

Open the torrent file in µtorrent with the file dialogue

Set the download directory to the location of the partially-downloaded files. (Note that while BC wants you to point to the containing directory, µtorrent wants you to be within that directory.)

Perform a manual hash-check (to assure that µtorrent does indeed see the download files at the correct %.)

Start the task.

I’m just not sure if that’s actually the question you were asking.

Bittorrent’s “speed” is an aggregate, adding all of the connections that it has made, together. It’s not going to have more than eight actively transferring at any instant, but they’re still added. The actual total depends on how much bandwidth each connection is allowed to use. This is, to the thinking of many, the ISP’s problem to solve (or not). Many ISP’s understandably do not agree, which is why some of them throttle bittorrent.

It’s the nature of computer networks to operate always and only at top speed, as that is affected by various things. They’re binary - as fast as possible, or off. Nothing in between. When a network is congested, the packets don’t slow down. Rather, they get crowded out, they never get sent, or expire while sitting in a queue somewhere waiting to be forwarded. The network merely appears, to its users, to slow down as packet-loss occurs. The electrons, and the packets, do not somehow travel slower. Rather I have to send the same packet five times before one successfully gets to you and your acknowledgement of it arrives back to me.

The corollary to this is that if a high speed path exists, the network will take it at high speed, whether that was the intent or not. If I establish a 100 Mbit link to a hub, and just do simple math on it, I can say this hub will support ten users at 10 Mbits each. In a certain sense, that is true, but you can hopefully grasp that my thinking hasn’t gone nearly far enough here, that if Charley over there is using 18 Mb of it, Joe’s going to think, from the 2 Mb he’s actually getting, that this network is really slow.

Take a real-world example, the coffee-shop hotspot. It offers 11 Mb/s over WiFi, but it’s just got a cheap wireless router to manage the bandwidth. That router lacks the capability to say “you get so much of my bandwidth and no more”, It’s not that sophisticated. One user can indeed crowd all of the others out, especially with something like bittorrent, that takes upstream bandwidth. In defense, the coffee shop turns on the router’s firewall, closes all the ports, and won’t even consider opening one. You can still P2P, but only slowly without a listen port, and the coffee shop will kick you out if they get complaints and find you doing it. This is the low-tech solution. It makes sense for the coffee shop.

It doesn’t make sense for the ISP, but making sense never stopped many of them. The right solution for some value of “right” is to technologically assure that you can’t take bandwidth away from anyone else. The half-assed solution is to throttle you, to assure that you cannot use any more than X bandwidth, whether the rest goes unused or not.

7

Thanks kluelos for pointing out some things. I’ve never took the time to think how “slowing” down of a connection translates at the lower layers of the network.

As you said, (if I got you right) since the line has the ability to support 1Mbps then it means the rest of us who have contracted lower dl/ul speeds (384kbps upload in my case) are kept at the said speeds by means of some control software or hardware on the ISP side. I’m just glad that my Bitcomet seems to have found a way around that. :smiley:

By the way, just out of curiosity and even if it may go beyond the scope of this topic, do you have any idea as to the technical details of how throttling is done by the ISPs?

As for the seeding task, yes thanks, that’s exactly what I was asking. And I was about to put your advice in practice when I took another look at the Statistics window in Bitcomet. This reminded me again that more than 75% of the said “high” upload speeds I’ve been noticing are due to LT seeding. In fact I’ve even turned off LT seeding and the upload speeds imediately went down to 43-46KBps which is exaclty my advertised max upload speed. So, since AFAIK there is no other client today which uses LT seeding it struck me that trying to seed the said files wiht another client would be pointless because the results wouldn’t be relevant.

One more reason for me to stick with Bitcomet. :wink: