dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
11
share rss forum feed


Selenia
I love Debian
Premium
join:2006-09-22
Fort Smith, AR
kudos:2
reply to asdfghjklzx5

Re: This is not about bandwidth

said by asdfghjklzx5:

There is a great article posted by George Ou about a week ago over at ZDNet about Comcast, (and now Cox's) "war" on bittorrent which sheds some light on the reason why they are resorting to these strange methods.

It's more about contention, than bandwidth. The cable node technology, being the archaic shared medium that it is, simply can't handle all the connection requests that bittorrent clients make and receive.

I encourage everyone here that wants Comcast's head on a stick to read the article I linked to above.
Thanks for the link. I manage networks myself(not at typical consumer level) and had overlooked a few points in there. Mostly the point they use hub topology prone to RTS collisions from the cable modems. I have had the luxury of dedicated pipes to switches myself. In this case, I guess resetting TCP connections is the only way. It might not even negatively impact BT if their threshold is reasonable and users set their connection limits to reasonable levels. The tricky part is the hogs might kill other BT users, since the threshold is probably still a global scheme. If they could run software that tracks stats per IP, then it might have no impact on anyone. Such software does exist but is very resource intensive and unnecessary on switched networks. It seems it would be useful in the RTS scheme though. Try testing lower connections and using at off-peak times maybe. I'd like to hear the results. Many people saturate their connections with peers to the point it would kill their performance on an unmanaged line, even.