Slashdot Mirror
Why BitTorrent Causes Latency and How To Fix It
Sivar recommends an article by George Ou examining why BitTorrent affects performance so much more than other types of file transfer and a recommendation on how to fix it. The suggestion is to modify P2P clients so that, at least on upload, they space their traffic evenly in time so that other applications have a chance to fit into the interstices. "[Any] VoIP [user] or online gamer who has a roommate or a family member who uses BitTorrent (or any P2P application) knows what a nightmare it is when BitTorrent is in use. The ping (round trip latency) goes through the roof and it stays there making VoIP packets drop out and game play impossible."
Hey, I have a really spiffy idea. How about creating a router that can determine which packets take precedence? I'll make millions off that idea...
What? Oh, damn Linux! What? Oh, Windows can do it too now? Why do I always have the good ideas about 10 years too late?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Don't download porn while playing WoW.
DD-WRT released v24 a week ago.
Although I do like to download a air few torrents here and there, I like to dabble in the odd online game although not as much as I used to. The amount of arguments and fights that come from people 'torrenting' in my gaming time is ridiculous. Almost as many as back in the day when we had 56k dial up and one phone line :P
Do you know how many times I've died in WoW because of his porn downloading?
He's paying up, I need my epic flying mount...
My ZooLoo
Good routers can prioritize traffic and limit the latency increase to the time it takes one bulk traffic packet to be sent.
Most P2P programs also have ways to limit the upstream bandwidth, which is sufficient if you are in control of your side of the bandwidth bottleneck. Just set the limit so that all bulk transfers combined leave enough room for realtime applications and the latency will sort itself out (because there won't be any queues of bulk packets building up in the router).
Why BitTorrent causes network bandwidth to be used. And network packets to be sent & received. Really sometimes I wonder.
i use torrents extensively (to distribute some home-made videos between a largeish group of members) and i have never seen the issues that blogger describes, despite me being the lone seeder for extensive periods of time.
the only "management" i ever do is shape the torrent traffic so that there is bandwidth left for other apps -- and i do that in the torrent software itself.
How is that news that good P2P download can saturate the bandwidth? And how is the question answered thousands if not millions of times in traffic shaping gateways comes in 2008 again?
Now, mod me down freely. My karma can't get any worse...
fixed it by buying a different cable modem (motorola). my linksys cable model got totally hosed by torrent traffic. no clue why, and I couldnt believe that the cable modem turned out to be the problem. I can torrent now whenever I want and it doesn't slow down traffic or increase ping or cause packetloss.. It's awsome!!
While I prefer Tomato on a WRT-54GL, that would do absolutely nothing at all to solve this issue. A router behind a modem can really only regulate the upload, and can't easily prevent a flood of data on the downstream side.
This issue is with the queue on the Telco's DSLAM, or on the other side of the cable from the modem. This is more like an invited DDOS, which no amount of filtering at or behind the modem can resolve, because the modem is getting the traffic from the DSLAM after it goes through the queue.
The only way to have QOS solve this issue would be to ask the telco to do the QOS for you, and the amount of processing power to do that nicely isn't trivial.
If I have nothing to hide, don't search me
Most router support QOS so if you run bt on one comp you can set that port priority to very low and it will help. if you got say Dlink DGL router. (http://support.dlink.com/emulators/dgl4300/Basic_Internet.html go under advanced then, click gamefuel)you can set up connections through certain ports to be limit its priority, usin that on mine i got 1mbit upload i can use 90-100kB/s up and nplay games with only at most 10ms increase
Use the bandwidth capping abilities in all modern P2P clients. If you're trying to torrent, max it's upload and download capabilities below your total network bandwidth. I have a 1Mbit up and 10Mbit connection. Capping my total upload in KTorrent to 100KByte/s and my down to 900KByte/s allows me to do anything else on the internet without issue. Very few online games or other uses of the internet require more than a 100KB down and 30KB or so up. Learn to properly manage your P2P programs and you won't have a problem.
Frozen Insanity
http://frozen-solid.net
So, if the ISPs do traffic shaping "to improve the service" it's bad, but we admit that on the small scale (when it affects ourselfs) there is a real need for traffic shaping! Thats interesting....
Homebrew traffic shaping. *facepalm*
I read the article. He's absolutely correct, and this would also solve the problems ISP's have with bittorrent. Instead of throttling bandwidth to all their customers and screwing them over, manage the traffic properly. It might slow down bittorrent downloads slightly, but not enough to seriously affect it. In the end however it doesn't make business sense for a monopolistic company like Bell to cater to it's customer's needs. They would rather force their customers to dump bittorrent and use their new video download service instead.
Why not just configure your p2p app to cap its own upload rate? Pretty much every single p2p app w/o exception has this option. Some dynamically cap their upload rate for you by periodically using ping (or measuring some other round trip time) to determine latency and continuously vary the cap until the ping stabilizes.
And we admit that on a small scale, we need to control our eating, but we don't want the grocery store telling us how much of things we can buy.
Traffic shaping and QOS will help a little, but the real problem is simply that you can't afford to delay priority traffic by more then one or two full-sized packets on any connection less then a few megabits (meaning: just about all home interconnects). If you wait any longer then that, it becomes noticeable.
Traffic shaping and QOS are not usually able to make that guarantee. A straight priority queue with bandwidth guarantees can, as long as you are able to actually classify the torrent traffic differently from your other traffic.
Part of the problem is that it is often not possible to distinguish between the batch and the interactive traffic with Shaping/QOS. Not only is QOS almost universally set wrong, but the simple fact is that one can mix interactive and batch traffic over the SAME ports (http, ssh, dynamically allocated ports)and that can make it virtually impossible to use traffic shaping or QOS to keep the mess away from your interactive traffic.
The best general solution is to use a straight priority mechanic with minimum bandwidth settings to separate as much of the bulk traffic out as you can, and then run fair-queueing at each priority level to take care of any that leaks through. This will do a very good job cleaning up the traffic. DragonFly has a fair-queue implementation for PF that does this. There is also at least one fair-queue implementation for PF in the wild.
Fair-queueing essentially classifies connections (the one in DFly uses PF's keep-state to classify connections), generates a hash and indexes a large array of mini-queues. One packet is then pulled off the head of each mini-queue. One enhancement I would like to make to the DFly implementation which I haven't done yet is to use the keep-state to actually determine which connections are batch and which are interactive, and have a parameter that allows the queue to give additional priority to the interactive connections by occasionally skipping the hoppers related to the batch connections. A quick and dirty way to do that is to simply check the queue length for each mini-queue.
In anycase, its a problem for which solutions are available. Regardless of what you use it has become apparent in the last few years that the only way one can classify the traffic well enough to properly queue it is by building keep-state knowledge on a connection by connection basis.
-Matt
We long ago learned that when inserting time between protocol events that it is far better to use a time randomized between an upper and lower bound than to use a repeating interval.
When fixed repeating intervals are used, separate instances of a protocol (and other protocols that use repeating intervals) slowly tend to fall into lock-step patterns with pulsating waves of traffic in accord with those patterns.
In other words, fixed protocol timers can create the traffic equivalent of the Tacoma Narrows bridge.
By-the-way, ping (ICMP Echo request/reply) is a terrible way to measure network latency. ICMP is often a disfavored form of traffic as it crosses routers, sometimes even rate limited.
There are better tools for measuring link properties, for example there is "pchar" - http://www.kitchenlab.org/www/bmah/Software/pchar/
I worked on a method to do even better measurements, but I put it aside several years ago: Fast Path Characterization Protocol at http://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html
http://lartc.org/wondershaper/
Works in Linux since 2002.
*yawn*
Wow, talk about solving a problem the hard way. Why not just use a bittorrent client which has rate limiting built-in? Which, by the way, is almost all of them? (I use rtorrent, an excellent command-line client.)
What about the upstream being flooded with ACKs?
The game.
Except, wait for it, almost all p2p clients allow you to throttle your bandwidth anyway.
I want to delete my account but Slashdot doesn't allow it.
It is always easier to manage uplink bandwidth from downlink bandwidth, simply by virtue of the fact that you control the actual packet queues.
Downlink bandwidth can be controlled in numerous ways. The easiest way is to actually run the incoming packets through a bandwidth limiter with a very large packet queuing capability. This will cause a ton of packets to build up in front of the limiter and eventually fill the TCP windows of the senders. The packets that get through the limiter will cause a stream of ACKs back from your machines at the desired data rate. The combination of the two will cause the remote senders to band-limit the packets they send to the bandwidth you desire.
when running incoming packets through a limiter you still need to traffic-shape/QOS, priority-queue, or priority-queue + fair-queue the packets going through the limiter. If you don't then your interactive traffic can wind up getting stuck in a packet queue with hundreds of packets in it. In addition to that you may have to control the advertised TCP window or even implement RED on your limiter to prevent the hundreds of packets built up in front of the limiter from turning into thousands of packets.
If you can classify the bulk traffic then you can use virtually any queueing mechanic. If you can't classify all of the bulk traffic then the only mechanic that will work reasonably well is, again, going to be a fair-queue.
Fair-queueing is not the holy grail but it is typically the most effective mechanism when combined with another queueing mechanic, such as a priority queue.
-Matt
BitTorrent does indeed cause noticeable slowdowns, but I use eMule all the time and I can even play games while downloading and uploading to hundreds of different peers.
It has been a little while since I worked with it, but Iptables for Linux (others?) basically had every options I could think of and then some. You can certainly prioritize things, set up different classes, etc, etc. Basically you can shape your upload so that uploads are only a little slower, perhaps only a few KB/sec. It will then correctly dynamically prioritize everything else.
Of course, the Iptables interface take a bit of reading. Perhaps someone knows a nice gui to recommend to generate the script.
Of course, some bittorrent clients can adjust their upload rate. For the casual downloader, it wouldn't be hard to keep that just under your connection speed to preserve latency and then maybe reduce it a bit more, or just pause it, when a call comes in to give some bandwidth for that.
I've wondered about this before, and I have tried, as many are suggesting, using QoS before. However, on our Linksys WAG354G QoS doesn't seem to do anything at all (when, luckily, all the latency is caused by traffic coming through under three ports, otherwise there aren't enough text fields in the QoS dialog to fit more), and in fact the router just seems to lose the DSL connection and not reconnect after a while, although I'm not 100% sure that's caused by QoS.
So, basically, when I want to play online nobody can use BitTorrent or P2P at all on the LAN... or indeed when anybody wants to browse, as BitTorrent lag sometimes gets so bad Firefox will wait several minutes on a connection that is never established, forcing you to hit stop and then refresh. At lower speeds it just stops it from downloading stylesheets (for some reason FF considers them optional), which is nearly as annoying.
"Let's face it, it's a good story. Accuracy would kill it."
You forgot protocol inspection
NBAR on any current cisco IOS feature set will detect pretty much anything you need to prioritise without seriously impacting performance.
Juniper has something similar on their gear as well.
Easy QoS: Low latency queueing = fair queue with a priority queue as you described.
tag real time traffic as priority queue and allocate enough bandwidth depending on your capacity engineering. tag your important apps and put them in the second queue. Rest in default class.
This is really all you need, I have seen VOIP for over 500 extensions hold up as that sites link is over 90% for an hour And this is Cisco callmanager i.e. the remote phones and gateways bork and go into fallback mode if the keepalives are lost.
Just need to remember it needs to be end to end and in both directions
IMHO, Cisco has the best packet queueing mechanisms that I know of. I've been using their fair-queue stuff for years, and it has only gotten better with each iteration of IOS.
When I went from a T1 to a DSL line to save some money I immediately noticed the missing cisco. That little 2620 was so nice. PF couldn't hold a candle to what the 2620's fair-queue could do so I sat down and wrote a fair-queue implementation for PF (for DragonFly). It still isn't as good as what Cisco has, but it gets a lot closer then the other PF queuing mechanisms get.
I think the bit I'm missing is the batch classification. My fair-queue can still get overwhelmed by dozens of batch TCP connections if I happen to not be able to classify their traffic (and they wind up on the standard queue instead of the bulk queue). The set-up is a priority queue with minimum bandwidth guarantees plus a fair-queue at each priority level.
I keep hoping someone will take up the flag and finish it.
-Matt
Not sure about other clients but Azureus at least allows you to set a QoS designator on all outgoing packets, leaving a router a very easy job of scheduling.
:)
At least one ISP here in AUS is looking at ways for customers to adjust their own shaping on the ISP end, so that you can get the perfect connection
...
Technology for mortals?
/. get back to actual nerd stuff?
"Incoming data from from multiple sources via the fast core of the Internet can sometimes clump closely together when multiple sources happen to transmit data around the same time."
More like technology for idiots.
It's simple. TCP/IP has a built-in backoff mechanism. It works wonderfully when two or three TCP (and other similar, more or less polite) streams compete for bandwidth. The mechanism is stream-based and not port-based, so when one app (one port) has 200-300 active streams, you're SoL no matter how polite those streams are. I guess one can approach the "BitTorrent corporation" with some crackpot idea about breaking TCP, but I wouldn't do it, unless you like to be laughed out of rooms.
What may work is a port-based backoff mechanism on top of the existing stream-based one, but no app vendor is going to be able to help you with that. Or get QoS configured on your router. Alternatively, just get your roommate to use BT traffic throttling. It's there for a reason.
Now can
Any whatsoever? His part in the Maynor/Ellch debacle was a serious low point for tech journalism; he makes Rob Enderle look good, fer chrissakes. Even if the article were in fact insightful and informative, the simple fact that his name is attached to it guarantees that I'm not going to read it. Someone please tell me what it says.
Yeah Cisco QoS is fantastic if configured properly. Work was nice enough to send two of us on the proper QoS course (straight out of the CCVP syllabus) so we got to see first hand how effective it is.
:) I hate wrestling with iptables commands but you could also do your routing / NAT on the dragonfly and only use the 2620 for Qos, its up to yu - heck you could even NAT twice if you want to be difficult LOL
The config is actually pretty simple IMHO, its getting the correct understanding that is the hard bit. (why do Cisco insist on their stupid bucket analogy!!)
Why don't you put your dragonfly (BSD I assume) box IN FRONT of the 2620? i.e.
WAN --> modem --> dragonfly --> 2620 --> switch
Then you can do your QoS, NAT and all your internal routing on your faithful 2620
Saturating your upstream (maxing your upload) means your downstream will suffer because you will be unable to send TCP ACKs as fast resulting in your internet to appear slower. Setting a worldwide limit on your entire outgoing traffics to just slightly below your maximum attainable upload will allow you to take advantage of giving maximum priority to your ACKs. Of course, on top of this one can also setup hierarchical queues for low bandwidth, high bandwidth and default queues (to keep it simple), but maxing your overall upload to just below your maximum attainable and giving priority to TCP ACKs are the best place to start...
Product placement anyone... Advert attached to this article...
A network card that claims to improve framerate and your gaming experience in general.... Can anyone say placebo!
# cat
Damn, my RAM is full of cats. MEOW!!
So, let me get this straight:
The geeks of slashdot acknowledge that P2P use strangles traffic on their LAN, and feel that some modification needs to happen to address this.
However, when service providers complain about the negative effects of millions of people using P2P on their backbones, and take action to correct this, same said slashdot geeks get their panties in a bunch and cry fowl.
I'm not taking one position over another. I'm just saying that I think this may be a big reveal about why a lot of norms have a strong mistrust and/or dislike of geeks. A lot of the time moral outrage is claimed when in fact it looks more like self interest.
George Ou's methods must be challenged because he's using Microsoft operating systems.
Peter Gutmann's methods are sacrosanct because he's targeting Windows Vista.
Of course, it doesn't matter that Gutmann is so full of shit that his eyes turned brown. It doesn't matter that Gutmann's methods were fatally flawed. (Anonymous anecdotes from message boards as authoritative sources?!) Peter Gutmann is a Holy Warrior of the One True License. To oppose him is to blaspheme before the Great God Stallman.
You're either with Twitter, or you're against him. Sound like a certain president you hate, you hypocrite?
Well then twitter, why don't you analyze his articles and come to your own conclusion, instead of spraying ad hominems on him just because he doesn't hate Microsoft as much as you obviously do.
The twitter monologues. Click on my homepage and be amazed.
It works like this: if the upstream bandwidth is saturated, TCP ACK packets get delayed and the sender slows transmission so the downstream bandwidth does not get fully utilised.
There is no solution other than throttling the upstream senders (AFAIK good P2P software has settings). Note larger send buffers in broadband modems actually exacerbate the problem by taking longer to flush. Best to keep them empty, and th only way is throttling.
I've been using a QOS mod for smoothwall 2.0 for about 5 years now: http://community.smoothwall.org/forum/viewtopic.php?p=164920 Works fine, not sure what everyone is whining about. It seems that QOS is some kind of black art or something. I have spent hundreds of hours trying to help people on that forum to get a good working qos setup and every time it just ends up being a waste of my time. People just don't take the time to read up on the technology that they are trying to implement and I just end up going around and around in circles. But what I can tell you is that no matter what the heck goes on on my network, no matter how much p2p apps are ran, I always have clear voip calls and lag free gaming. I remember seeing an article about a device that was supposed to automatically shape your traffic and give you lag free gaming and stuff. I am sure it never took off because as it seems no matter how simple you make QOS, people still can't figure it out.
I like the way linux bandwidth arbitrator (http://www.bandwidtharbitrator.com/) approaches the problem.
-
Set your total bandwidth minus the guaranteed bandwidth you want to allocate to priority traffic masked/identified either by port/protocol/src/dest or by a deep packet (perl based) inspection.
-
If any app OR host OR connection OR port starts encroaching on the latency of other others, it gets chucked into memory jail for a fixed number of escalating milliseconds.
-
This has a two fold benefit for latency and bandwidth contention issues. One, by chucking the hogs in memory jail, queue space is cleared up to allow priority traffic through on a more consistent basis.
-
Imagine you've got a city bus that goes to sports stadium of your chosing. When it's not a
game day, there are no problems boarding the bus. You get 3 or 4 people on their way home from or to work. On a game day though, you get those same 3 or 4 people plus an additional 20 drunk people who don't know how to board a bus. What usually happens is the 3 or 4 regulars either don't get a seat or have to wait until the next bus. Not good or fair.
-
The way linux bandwidth arbitrator solves the problem is to tell the bus driver to watch for drunk idiots. If she sees more than three cubs fans in a row, she shouts out to them to step back, close their eyes and count to 10. While they're doing this (they're cubs fans, you know they would), she waves the regulars to the front of the line.
-
So, it's good for latency and jitter. It's also good for bandwidth. All those bad packets you threw into memory jail? Well, a good portion of them are probably TCP which means there's a remote end of the connection waiting on an ACK before it sends more data. Even in the case of connectionless protocols like UDP, chances are there is some sort of app or session layer check that will defacto hold back sending more data until it receives a response. You've managed to stem the firehose that's half of the problem without resorting to cheap ass tactics like false RSTs.
-
The beauty is, done right you don't need to know anything about the problem causing traffic to mitigate its effects. Assume you tag your priority packets with a deep inspection based on port/src/dst/prot (This is what almost never gets done). Whether it's eMule is running on port 443 or through a proxy or if it's a worm or the file sharing program of tomorrow, it gets throttled back.
-
The drawback is it's a bitch and a half to get installed and three more bitches worth of pain to get configured and tuned. Once you do though, it rocks.
-
[I kid about cubs fans. I lived off of Addison Ave and dealt with my fair share of that scenario, but the bulk of the people in line were ok.]
I think you may be using different units (kbps vs KBps) than he is using.
850 KBps = 6.6 mbps
70 KBps = 560 kbps
I use RR also, and those are both reasonable numbers.
http://www.cypherpunks.to/~peter/zdnet.html Schneier is a moron if he thinks telling Hollywood no will force them to use non-DRM content. All you need to do is look at the CableCard fiasco. You give Hollywood the finger and they give you the finger right back because they'd
rather NOT have any content on the PC to begin with. Like Apple, Microsoft
will humor Hollywood so they come join the party. Once they're in, they'll
get screwed out of their DRM protections because Microsoft won't patch the DRM
holes and let their customers bypass DRM. The latest DRM stripper for Windows
Media has worked for almost 2 months now and Microsoft hasn't patched it yet. Ok, so it's nasty to call someone a moron. And it's not really true either. It's ideology that causes Schneier and all the Web 2.0 'experts' to say this. He's no fool but he can't differentiate between it would be good if something being true and something being true. It would be good if Hollywood would give up on flakey DRM schemes. But if Microsoft and Apple had somehow agreed to boycott them, then Windows and Mac users would just have been left with no way to play HD content, because Hollywood is mortally afraid of people ripping HD content and uploading it to Pirate Bay. But George Ou is right that once stuff gets on open platforms like the PC it will get cracked anyway, so the OS vendors were just humouring them. And they probably knew it. FOR THE LAST TIME, I want the DRM on my system so I can play my DVDs, HD DVDs,and Blu-ray like MOST people.
You don't want it, more power to you. I've given you the links to the
software you need get avoid enabling MFPMP at all. I've shown you the lower
CPU utilizations using cheaper hardware. I don't know what else you want. ...
You know, you are a f***ing moron. End of discussion. Well, he's certainly tactless and outright rude. But he's also right about the following -
* Hollywood forced OS vendors like Microsoft and Apple to add DRM to allow playback of HD content.
* Both did, because it would be hard to sell an OS which can't play next generation content.
But this doesn't really matter because
* DRM will be cracked anyway.
* It doesn't have any effect on the OS if you don't use HD content.
He's only get flamed because he's defending Vista which is the subject of the current geek 3 minute hate. Now I don't really like Vista compared to XP, you don't need to believe that it 'causes global warming' as he puts it to dislike it.
BluRay is a product. If you don't like, don't buy and don't use the content distributed over it. I know I won't. And if you don't want Vista as a bundled OS, buy a computer it doesn't come on (like a Dell) or build your own.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I had major issues with bittorrent, NNTP, and other bulk file transfer applications causing massive latency for my VoIP line. I tried a few things but nothing worked out. I ended up settling on a combination of Snort (to detect when I'm on a VoIP call), pfSense (a box to host the application on), and a Cisco router to rate limit only while I was on a call, to get flawless VoIP even with bittorrent running.
Substitute "VoIP" for online game if you wish... the concept is the same. The nice thing about this method is that 100% of the bandwidth is available for bulk file transfer when important applications are idle, but when they fire-up, rate limiting takes enough bite out of the file transfers to make the VoIP work well.
I call it Application Aware Triggered Quality of Service or AATQoS for short. Read the how-to on the webpage.
who the hell modded this up? doesn't everyone know by now that this is one of twitter's sockpuppets?
Well actually every good consumer router already does that. For example with mine, I can define 4 types of packages and impose certain bandwidth levels on them, as well as set priorities. It's a basic feature of many DSL-Routers.
You have been called on this before twitter, please don't trot it out again hoping someone with moderator points won't remember it and not realize how blatant your misrepresentation is.
If you'd bother to read the article you'd discover that not only does this not work, but the article explains why and, in fact, that's the whole point of the article.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
I've used both stock debian and m0n0wall and I run my torrents unlimited up and down. I've never had an issue once I get the qos dialed in. Yes, it takes a bit of tweaking on the numbers, but once it's set neither I nor the person I'm voiping/gaming with can tell there's a torrent even running. Latency can go up slightly on web browsing, but that's where Ou's recommendation for a smaller p2p packet would really help.
db
I am literally 3000 tokens away from the chaotic crossbow --Stephen
The hundreds of p2p connections crashing routers has more to do with their lack of other resources. M0n0wall, for example, has a connection table that maxes out at 30 thousand entries. You are not likely to saturate this at home, and if you did, you still wouldn't crash the router, you would just have to click that link a few times in your browser before succeeding to load a new web page. I suspect the common lockup of OTC routers under p2p load has more to do with a lack of RAM.
db
I am literally 3000 tokens away from the chaotic crossbow --Stephen
You probably just need to limit your download or upload rate more to prevent excessive queueing at the ISPs routers. What I usually do is start by setting up a continuous download/upload and continuously pinging a server (or two) which is known to respond quickly to pings. Once you do that you can simply use a binary search (looking at the ping times as an indicator) to find out what your download/upload should be.
HAND.
Plain and simple.
Maybe he used more sophisticated tactics than "Well, I don't seem to be lagging", but I could cap a torrent at 100kbytes out of a 2 megabit connection -- so, roughly half -- and no lag. Since I got fiber, I simply cannot saturate my pipe thoroughly enough to cause significant lag.
Don't thank God, thank a doctor!
If the ISP wants to make the shaping opt-in, and give me a website to visit to shape my own bandwidth, I'm all for it. It might be easier than trying to shape my own traffic.
But if the ISP is going to choose for me, no thanks. I'd rather you just actually give me my full pipe and let me use it how I want.
And believe it or not, I seem to actually get that, on a fiber connection, for $60/mo. In rural Iowa.
By the way, this is the solution to how to have net neutrality, and still have working VoIP: Actually build enough infrastructure that you can handle users actually using their bandwidth. Then, it's entirely up to them how they want to shape it.
Don't thank God, thank a doctor!
More seriously: Me shaping my own traffic is very different from someone else shaping my traffic against my will.
To borrow another poster's analogy:
I have no problem with choosing what kind of food I eat. If I had kids, I'd have no problem choosing what kind of food they eat.
I would very much not like the grocery store to choose what kind of food is best for everyone.
Fortunately, it's in the grocery store's best interest to give customers what they want. For some reason, ISPs think it's not in their best interest to do the same.
Don't thank God, thank a doctor!
Install a bandwidth management tool like cFosSpeed and you will see that latency drops down to essentially the same levels as you have without BitTorrent running without reducing the torrent speed whatsoever. This doesn't even require any of the fancy prioritization features of the bandwidth manager tool - just avoiding overloading the transmit queue.
In other words, your DSL line is perfectly capable of handling an uplink that is actually used for more than an occasional HTTP request without bogging down. The reason it doesn't do it is poor engineering of the DSLAM. With better tuning and queue management algorithms like RED (Random Early Drop) they will cooperate with TCP congestion control to avoid overloading the uplink buffers. Your DSL line will work just fine without a third-party bandwidth management tool.
Why is the DSLAM poorly engineered? The simple explanation is incompetence. Conspiracy theorist would probably claim that it's intentional because ISPs don't want you to use bandwidth-intensive applications. The truth is probably somewhere in the middle: the original flaw was a combination of lazy engineers and the fact that most users don't really use their uplink so much. It's not being fixed beacuse it serves the interests of the ISPs.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Even just priorizing ACK packets in your upload channel can make a tremendous difference to your ping!
READ THE ARTICLE.
It says and i confirm, even 10% of torrents upload capacity makes still latency high.
There is a nice graph in that site. First picture says what it is now, big trains wait on intersection to go over. Second picture says, using packed prioritizing you can send smaller and important trains first, but there will be still big ones and if you go in on bad moment, when big train just crosses over that bottleneck, you still get latency. Third one is basicly the same, difference is, biggest trains are now smaller and worse case scenario end with less latency. Well, there is catch, more packets, more payload, throughput is smaller, you can put less information through of that bottleneck.
QOS make latency small, smaller torrent packets makes it even more smaller.
I'm having a Azureus running all the time, and I do make SIP calls from my mobile, over the same WLAN that my laptop uses.
Hint: QoS on the router, and/or, you know even the first bittorrent client had a way to limit the upload rate.
Hint2: Manage your output queue. If you let bittorrent max out the output queue of your DSL/cable modem, well, bad luck.
To summarize, the author should get clue.
Some special gems:
> Now it is possible to solve this problem on the network level by prioritizing VoIP and gaming packets in the home DSL modem upload queue.
> Unfortunately, I don't have administrative access to the modem and implementing VoIP or gaming prioritization on my home router seemed to have no
> effect because there is nothing in the transmit queue of the home router since it connect to the DSL modem at 100 Mbps. Packets in the home
> router get forwarded as soon as they arrive and there is nothing to reorder in the queue because there is nothing in the queue. More advanced
> business-class routers like those from Cisco will allow you to configure the speed of the FastEthernet connection to match your DSL throughput so
> that the queue will migrate from the DSL modem to the router but this isn't very practical for most people. So it would make sense for
> application writers to try and make their application work as well as possible on the majority of home networks and broadband networks without
> QoS.
Guess my Asus router is a business class router then. Hmmm, well, the upgraded Linux firmware then. Obviously, it's better to rewrite every network application that sends data to do a distributed QoS, than to do it on the router. Hmmm, did the author check how well Microsoft FTP client blocks the connection? Wouldn't that be an peachy subject line for your next article? "Microsoft FTP needs to be rewritten". Better yet, you know MS has these WEBDAV support? "MS Windows needs to be rewritten to not disturb my VoIP calls!"
Other cool subjects like "MS Networking needs to be rewritten because the author is to stupid to buy the right router and/or configure his router"
come to mind.
yacc143
In a DMZ, SOME of the ports are open directly to the internet. Not ALL of them. Some.
Cracking DRM is illegal in some countries. Is George Ou saying its better to break the law in this way than not have access to certain media? If that is the case, then why bother buying and cracking at all, its far easier to download it from the piratebay. You avoid the hassle of having to crack the DRM and the cost of having to buy the media/DRM software tax. Its just as illegal either way.
Caesar si viveret, ad remum dareris.
-nt-
DRM: Terminator crops for your mind!
Maybe if you use some badly programmed client running on some garbage OS with a shitty TCP/IP stack, it might happen (maybe a weird ISP comes into play too).
I happen to have 2 bit-torrent clients (mldonkey and rtorrent) on my home network running 24/7 (constantly uploading popular stuff, including things like linux distro ISOs) and that doesn't prevent my brother to have a decent ping in Phantasy Star Online, Ragnarok, Lineage 2, Cabal or Age of Conan (In case of the later at least as long the server is holding up at the other end. Of course during the launch week of such an anticipated games, there's bound to be minor hoops), while at the same time my father's Skyping to some other family across the globe. That means that even though your upload rate may be limited to 10 KB/s, if your total upload is 20 KB/s, you might experience a maximum lag of 0.5 seconds. Then something is really wrong with this guys' software. In-client bandwidth shaping is supposed to be done at the request-level. A well behaved client is supposed to keep in flow enough request to keep the traffic constantly within ranges of aloted bandwidth (i.e.: don't try to simultaneously push packets toward 2534 different peers, if upstream is limited to 20KB/sec).
mldonkey, for example, has an algorithm which limits the number of peers its uploading to based on the upload limit. It won't serve more packet than it should to avoid over filling the outbound queue in the DSL modem.
You can further control this by manually overriding this number, limiting the total amount of connections kept open at any time, etc.
In the same way, a DSL modem is supposed to evenly distribute it's outbound traffic to all clients in the LAN. It's not supposed to suddenly shut everyone else on the network and only serve the P2P-running server for short bursts of time.
I'm not even speaking about advanced QoS like traffic shaping and prioritizing based on services. I'm just speaking about basic "spread the bandwidth evenly among all members of the LAN".
This guy should change its client. And maybe his router too.
The same goes for down stream : a client shouldn't send too much requests to the point that the whole intertube suddenly starts giving back data payload at the very exact same time. That would be the equivalent of client self-DDOSing itself - that's either an idiotic client or an extremely badly done configuration.
In a similar way (as long as the number of requests are within reasonable range) there's no reason why, when the wait queue grows in the DSLAM, it should suddenly start neglecting some of the request and not the other (the VoIP & MMORPG packet shouldn't suddenly get pushed to the end of the queue while the DSLAM first transmits all P2P packets exclusively). The DSLAM should evenly send packets to all open ports.
But probably the ISP tried to get away with the cheapest possible material. And instead of doing something intelligent upgrading material and/or implementing packet prioritizing (no matter what, if there's a VoIP connection open, it should get a minimal constant flow of packets - Avoid at all cost temporarily pausing the flux while bursts arrive) the ISP are whining and trying to lobby to be allowed to do traffic capping.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
If you want a laugh, go through Freedom to Tinker's archives and look for the BitTorrent threads George Ou has posted on. For example, this one. Every time he opens his virtual mouth, he flushes a little more credibility down the toilet.
Visual IRC: Fast. Powerful. Free.
Let's take the whole thing from the top.
1) Microsoft's marketing department decided that Vista needs to support BluRay.
2) The BluRay Disk association said that if they want to do this they need to support protected media paths and all the other nonsense.
3) Microsoft did that.
4) The net result is that you can Windows Vista and a software player to play BluRay DVDs. You don't need to crack anything to do this, or break any laws.
If they hadn't implemented PMP et al, you would need to crack to watch the disks because no software players would have been licensed by the BluRay consortium. I read somewhere that with DVD they originally planned not to allow software players because they were scared the keys would leak. And they were right, the Xing Mpeg player was hacked and the key was discovered.
http://en.wikipedia.org/wiki/Xing_Technology
So they sort of had a good case for only allowing hardware players. But Microsoft convinced them that PMP and so on would avoid cracks. Inevitably one of the software players was cracked.
http://en.wikipedia.org/wiki/AACS_encryption_key_controversy
Note that Windows DRM is 100% ineffective against this sort of thing, which is why PMP is a bit of a con. You can always use WinDbg to kernel mode debug a Windows machine and read every single byte of memory. But from what I can tell, the AACS key was extracted from the user mode software player, so even this wasn't necessary.
But you don't need to know the crack anything to play BluRay discs on Vista. Just use the BluRay player software that came with the machine. But that player would not have been licensed if Microsoft hadn't implemented DRM in the OS.
Now Linux can't implement DRM that will satisfy the BluRay consortium that a user won't get the keys. So to play BluRay discs on Linux you must rely on the crack. But cracked software isn't exactly user friendly. It's illegal to link to it in the US and the studio will keep tweaking the disks so it breaks and you need to download a new version.
If Microsoft hadn't implemented DRM the Windows users would be in the same boat.
Now if Blu Ray is like DVD then writable disks will only allow unencrypted content. So to copy a Blu Ray disk you'd need to crack. But just to watch a disk you don't.
Personally I pretty much rent or buy the odd DVD and watch cable. I'm in Asia and BluRay isn't too common here. I think the technology is overpriced and the requirment that the whole playback path be protected makes the whole process too fiddly. I can't see much difference in quality between HD and normal content. So I'm not going to buy it. But let's not get carried away. Windows users will watch BluRay disks in a userfriendly way. Pirates and Linux users will be able to copy/watch it too, it will just take a bit more work.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Let us take this occasion to have a moment of silence for the above AC's sense of humor. It died in a tragic accident and all attempts at resuscitation failed. It will be missed.
He fires up Bittorrent and his network connection turns to crap. Is his ISP Comcast by any chance? Kidding aside my first thought was he's viral for the telecoms to redirect and mis-direct the problem to the client.
-[d]-
Not sure about anyone else here, but traffic shaping only works to an extent. One of the things regarding my Juniper Netscreen is that it has impressive traffic shaping abilities--except, it only shapes per connection direction.
Meaning, since most of the problem comes from torrent *upload* (which is an inbound connection), you won't be able to QoS that to a lower priority than your web traffic (outbound connection).
Essentially, you get about the same effectiveness as simply capping using the program's rate limiting options.
We all know that completely using your bandwidth will make your connection slow. If it's still slow after limiting bittorrent bandwidth then there's another reason. Most clients utilize many more connections than the operating system supports. People think "Ohh more connections means I can download faster." Just lower your number of connections for your client and this problem will fix itself.
Now imagine sending 10 private emails to someone (Karel Donk) and the guy continues saying annoying and idiotic things. Then imagine you lose your temper and use some profanity in a private email. Now most people can get away with that, but someone like me who is a high-profile blogger at ZDNet should have known better to write that in an email. So Donk forwards my emails to Gutmann and Gutmann posted it on that link of his pretending like I was sending Gutmann harassment email. Initially, Gutmann posted it on his University web page but he took it down because it didn't belong there. So that was Guttmann's only defense that I referred to him as a moron in some email that wasn't even sent to him.
So I used profanity in a private email and it got posted without the full context. I should have known better and I won't make that mistake again. Guttmann on the other hand never conducted a single test, never even used Vista, and he presented a bunch of web forum postings as a scientific study from a respected university. That is by definition academic misconduct.
I explain how Karel Donk is one of Gutmann's primary sources here. http://blogs.zdnet.com/Ou/?p=723)
Anyhow, thanks for being logical and email me any time.
You can slow down traffic, even in the p2p application. But it will negatively affect transfer speed of p2p applications. Specially if you communication with other high latency clients.
And it is not easy to do under windows because properties like frame window size is not accessible from windows in a generic way.
I regularly download gigs of data via Bittorrent and my wife simultaneously uses a java based IRC client, while I play COD4 and I still get on average no more than a 40 ping in my fave server. Normal ping is around 33, so a whopping 7 ms latency surely that's acceptable, at least to me. Oh yeah, I've also done all that and run my own audio stream server, all from my home network, and my games are still very much playable. Using cable medium bandwidth tier.
I am Bennett Haselton! I am Bennett Haselton!
Back when I had my computer plugged right into my cable modem I never had a problem with bittorrent slow downs at all. I had probems even surfing properly with bittorrent on once I added a router. Configuring QOS seemed to do nothing. You're DOSing your own router with too many open connections, it has nothing to do with bandwidth. Some routers are better able to handle hundreds of connections then others. The old linksys wireless routers (that most people still use) are garbage in this regard.
Need more seeders.
Most bittorrent clients are configured to use far to many connections at any one time.
While saturating your upload is a bad idea, setting it to 75% should typically (for 512 kbps and faster upstream) leave plenty of room for an FPS and a VoIP call.
Even if you cap it at 50% you'll typically run into issues because there are so many connections open. What's the point of seeding to 50 people at 1 KBps when you could seed to 5 at 10 KBps?
The excess of connections is the problem. Cut the standard to about half unless you have a powerful router and modem (no, DD-WRT doesn't make your router powerful, and no, that modem the cable guy gave you isn't special either).
If you ever run into him elsewhere (or even in meatspace), his real name is William H. Hill, works at LSU and lives in Baton Rouge, LA.
I imagine lingo is probably using UDP instead of RTP otherwise his ISP should be able to provide QoS for his voice traffic? I'm not sure if the author is trying to make a case against network neutrality but it seems he does not understand that QoS can be provided without reverting to some kind of ISP mafia pay scheme.
Peter Gutmann can be trusted because he's an independent expert who's usually right. He's a academic imaging expert with no concealed interests and someone who cared enough about Windows to investigate Vista. His account of being raped in the Wintel press for it is well written. Ou took it to the next level by writing letters to Gutmann's University to get him canned. All of this because Gutmann dared publish a careful and objective review of Vista's DRM. Everything Gutmann said has proved correct.
And I am only partly being facetious here, get rid of the roommate!
Gutmann's useless "research" must be central to your little jihad if you're so desperate to convince people that it's somehow valid and implying that anyone who thinks otherwise "hates" you.
Please reply to Allador's points, and have the decency to apologize to George Ou (who has posted in this thread) for insulting him.