Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Networking The Internet

Why BitTorrent Causes Latency and How To Fix It 315

Posted by kdawson from the first-mile-downstream-would-still-hurt dept.
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."
This discussion has been archived. No new comments can be posted.

Why BitTorrent Causes Latency and How To Fix It More

Why BitTorrent Causes Latency and How To Fix It

Comments Filter:

  • QoS? (Score:5, Funny)

    by Opportunist ( 166417 ) on Sunday June 01, 2008 @05:58PM (#23620975)
    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?

    • Re: (Score:2, Informative)

      by Anonymous Coward
      OpenWRT or DDWRT can run some nice QoS scripts to filter based on ip/port/service

    • Re: (Score:3, Insightful)

      by ILuvRamen ( 1026668 )
      yeeeeeah or for free, you could just cap the bandwidth your client uses. I cap it at 25KBps up and 400 down out of my approximate 70 up and 850 down (Road Runner) and I play MMORPGs under those conditions just fine.
      • Uhhh... DD-WRT is free. I use it on my WRT54GL, and it works marvelously.
      • Did you even read the article? The entire thing was about how you could avoid having to ask other people to use the network with a lighter touch.

      • Re:QoS? (Score:5, Insightful)

        by schnipschnap ( 739127 ) * on Sunday June 01, 2008 @08:25PM (#23621983)
        You should have taken a quick look at the article first. The author basically experienced excessive lag even though he did cap his upload rate, compared to what an upload or download via a different protocol (FTP, HTTP, VoIP) would cause. This is because the BT client fires or receives packets whenever they are available, while the others receive or send packets in a spaced manner (unless they saturate the pipe). 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. The guy put up a lot of graphs to illustrate that it happens quite often actually. It seems that he got those patterns with the "official" client and with Azureus.

        • Re: (Score:2)

          by BLKMGK ( 34057 )
          Yeah maybe but my experience playing first person shooters that are latency sensitive doesn't reflect his experience. I can play UT3, UT2K4, Eve too - no issues. I see pings as low as 35ms in UT2K4, I set my upload as high as 100kbs - this is a 15/15 fios connection, downloads hit as high as 1.7mbs.

          • Re:QoS? (Score:4, Informative)

            by xenocide2 ( 231786 ) on Monday June 02, 2008 @12:30AM (#23623463) Homepage
            I've noticed similar problems at my place, and I think it's less about burst packeting and more about fair queuing. Bittorrent opens up tons of connections and VoIP doesn't. It's not that there's no time to send communications on a regular interval, it's that the VoIP app isn't getting them. In my case, I'd been pondering the ins and outs of Tomato's QoS but I mostly just throttled Deluge and called it a day when that did the job.

    • Re:QoS? (Score:5, Informative)

      by pin0chet ( 963774 ) on Sunday June 01, 2008 @06:26PM (#23621193)
      OpenWRT and Tomato feature impressive QoS capabilities as well.

      L7-filter can even manage traffic at the application layer. Just set Bittorrent to "Bulk" and put Skype and Xbox live as "Premium."

      Managing traffic on the router level is a lot easier than on the PC level, especially when you have several devices on a single network competing for scarce bandwidth.

      • Re: (Score:2)

        by dattaway ( 3088 )
        That worked several months ago...

        I have L7 on dd-wrt, but the torrents start using encryption on port 443 almost immediately. So I block 443, then they start using random ports. Its like a game of whack-a-mole with a large fleet of computers. Try to meter one port and two more pop up. The end result is a computer saturating bandwidth with endless connections over the full range of ports.

        • Re: (Score:2)

          by mrbooze ( 49713 )
          So why not make "Bulk" the default traffic classification and selectively identify the legitimate traffic that deserves higher priority? Now all bittorrent traffic is bulk no matter what port or encryption they use.

      • I've been running OpenWRT for about a year now and have had no problems at all with my voip traffic getting clobbered by bittorrent. I also provide the NOAA audio for my city's listing in weatherunderground.com 24/7 and that never seems bothered either.

    • QoS, but only on the Telco Side (Score:5, Informative)

      by corsec67 ( 627446 ) on Sunday June 01, 2008 @06:27PM (#23621203) Homepage Journal
      While I prefer Tomato [polarcloud.com] 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.

      • Re: (Score:3, Insightful)

        by wintermute000 ( 928348 )
        Hear, hear

        I love these home geek "i know how to flash DD-WDT and click on a GUI" networking experts, who fail to grasp your point above (i.e. QoS = OUTBOUND).

        Since downstream QoS from telco aggregation router is not practical to implement, the best fix is to throttle the clients on the end user PCs, free and just a few clicks away.

        Or if you want to be really advanced, QoS outbound from a second router (or linux gateway or firewall etc.) behind your WAN router but really that's overkill for 99% of users.

      • Re: (Score:2)

        by tepples ( 727027 )

        A router behind a modem can really only regulate the upload, and can't easily prevent a flood of data on the downstream side.
        Can't a router delay ACKs for "bulk" level services?

        • Re: (Score:2, Informative)

          by Zan Lynx ( 87672 )
          Yes, and delaying ACK or dropping inbound packets will help...but only for long-running TCP sessions.

          UDP or IP protocols do not care at all, and TCP sessions don't slow down until they realize packets are being lost which can take up to 10 packets per connection.

          So when remote BT clients hit with 6 incoming TCP sessions, that is at least 60 packets without any rate limit. And BT will do that over and over again.

      • Re:QoS, but only on the Telco Side (Score:5, Informative)

        by Bruha ( 412869 ) on Sunday June 01, 2008 @09:46PM (#23622529) Homepage Journal
        That is completely false. QOS features have long been supported by CEF and many other ASIC based solutions in Cisco and many other service provider equipment. For many years now it's been there and has been ignored. At my company I have been preaching QOS to make sure that user experience is guaranteed. Routing protocols get first shot, then HTTP(S)/Telnet(SSH)/POP3/IMAP/SMTP etc etc. Every other app is regulated to bulk. Then that 95% will never see latency of problems with their web surfing and even games such as WOW DOOM, Xbox live etc can get priority queues over bulk downloads.

        Once it's done at the network level the same can be applied down to the user level with the packets as they're tagged.

        What we lack is ways for routers to signal upstream routers for dynamic QOS to the customer network.

    • Re: (Score:3, Interesting)

      by yabos ( 719499 )
      The 3rd party firmware products like dd-wrt and tomato only does upstream QoS by default. You can make your own iptables script for the down stream though. I'm not sure how it works in implementation but I've set mine to give http full bandwidth over nntp on a certain port.

      When I'm not using http to download something then nntp can download at full speed. When I do something on http it will get the full bandwidth. It's not instant though so it takes a few seconds to kick in. I suspect it's dropping AC

      • Re: (Score:2)

        by kesuki ( 321456 )
        "You can make your own iptables script for the down stream though. I'm not sure how it works in implementation but I've set mine to give http full bandwidth over nntp on a certain port."

        this is why i like smoothwall, the best part of smoothwall is that it will run on slow, cheap computers, some have even managed to get it to run on 386's. I know old computers use more power than a linksys, but you can get a new computer based on cheap System on a chip parts, that uses about as much power as a linksys, but

    • Re: (Score:2)

      by ATMD ( 986401 )
      I've set QoS up on my (Gentoo) router manually using tc, and it helps a bit but the internet is definately a lot slower when people are torrenting. I'm not even talking about stuff with low latency requirements - simple web browsing becomes several times slower, and if someone's set their BT client to unlimited upload then even with my QoS, about a third of HTTP connections time out or never establish in the first place.

      I don't want to use L7 because I'm trying to /reduce/ lag, not spend precious milliseco

      • Re:QoS? (Score:5, Informative)

        by Dolda2000 ( 759023 ) <fredrik@dolda2000. c o m> on Sunday June 01, 2008 @07:27PM (#23621635) Homepage
        It sounds like you're doing it wrong. I've set up HTB shaping with tc on Linux as well, and it works very well. Flawlessly, I might even say.

        There are two key points:

        • You absolutely need to limit to absolute maximum outbound bandwidth (on the root qdisc, in other words) to a value slightly below your real outbound bandwidth. This point is critical. Without it, there's no point in even trying to shape the traffic, since the modem will start buffering.
        • It helps very greatly if it is possible for you to classify torrent traffic into a HTB class with lower priority than whatever class the packets you care about go into. There are several possibilities for going about that:
          • If the program in question supports setting the DSCP field of the packets (where the TOS field went previously), you can use iptables with -m dscp to set the fwmark on them to classify more precisely (remember to clear the DSCP field before sending the packets out from your network, though).
          • If a program running locally on the router does not support setting DSCP values, you can create a group, set the program to SGID to that group, and use iptables with -m owner --gid-owner $GROUPNAME to set the fwmark. The same method can be used to set the DSCP field on packets from a Linux machine other than the router.

        For reference, here is the script that I use to set up the traffic shaping. It might prove useful to you.

        #!/bin/sh

        # Current bandwidth allocation:
        # 1:11 1:121 1:122 1:13 1:14 1:15 1:1
        # (25 + (175 + 75) + 125 + 175 + 25) = 600

        tc qdisc add dev wan root handle 1: htb default 122
        # Root
        tc class add dev wan parent 1: classid 1:1 htb rate 600kbit ceil 600kbit cburst 1500 burst 50kb
        # TOS Min-Delay
        tc class add dev wan parent 1:1 classid 1:11 htb prio 0 rate 25kbit ceil 50kbit burst 10kbit
        # Bulk
        tc class add dev wan parent 1:1 classid 1:12 htb prio 1 rate 250kbit ceil 600kbit burst 10kb
        # HTTP
        tc class add dev wan parent 1:1 classid 1:13 htb prio 1 rate 125kbit ceil 600kbit burst 50kb
        # FTP (Needs iptables support)
        tc class add dev wan parent 1:1 classid 1:14 htb prio 1 rate 175kbit ceil 600kbit burst 10kb
        # Low priority
        tc class add dev wan parent 1:1 classid 1:15 htb prio 2 rate 25kbit ceil 500kbit
        burst 10kb
        # TOS Max-Bandwidth
        tc class add dev wan parent 1:12 classid 1:121 htb prio 1 rate 175kbit ceil 600kbit
        # Default
        tc class add dev wan parent 1:12 classid 1:122 htb prio 1 rate 75kbit ceil 600kbit
        # TOS Min-Cost (Needs iptables support)
        tc class add dev wan parent 1:15 classid 1:151 htb prio 2 rate 5kbit ceil 400kbit burst 10kb
        # Auxiliary low prio bands
        tc class add dev wan parent 1:15 classid 1:152 htb prio 2 rate 5kbit ceil 400kbit burst 10kb
        tc class add dev wan parent 1:15 classid 1:153 htb prio 2 rate 5kbit ceil 400kbit burst 10kb
        tc class add dev wan parent 1:15 classid 1:154 htb prio 2 rate 5kbit ceil 400kbit burst 10kb
        tc class add dev wan parent 1:15 classid 1:155 htb prio 2 rate 5kbit ceil 400kbit burst 10kb

        # Filters
        tc filter add dev wan parent 1: protocol ip prio 1 handle 11 fw flowid 1:151
        tc filter add dev wan parent 1: protocol ip prio 1 handle 12 fw flowid 1:152
        tc filter add dev wan parent 1: protocol ip prio 1 handle 13 fw flowid 1:153
        tc filter add dev wan parent 1: protocol ip prio 1 handle 14 fw flowid 1:154
        tc filter add dev wan parent 1: protocol ip prio 1 handle 15 fw flowid 1:155
        tc filter add dev wan parent 1: protocol ip prio 2 handle 1 fw flowid 1:14
        tc filter add dev wan parent 1: protocol ip prio 3 u32 match ip tos 0x10 0x1e flowid 1:11
        tc filter add dev wan parent 1: protocol ip prio 3 u32 match ip tos 0x08 0x1e flowid 1:121
        tc filter add dev wan parent 1: protocol ip prio 3 u32 match ip sport 80 0xffff flowid 1:13
        tc filter add dev wan parent 1: protocol ip prio 3 u32 match ip sport 443 0xffff flowid 1:13

        # Leaf nodes
        tc qdisc add dev wan parent 1:11 handle 2: sfq p

        • Re: (Score:3, Informative)

          by ATMD ( 986401 )
          That's similar to what I have, albeit with more rules and finer-grained control. Mine basically says that if the outgoing packet is > 1kb then it's probably part of a high-traffic connection and needs to be shunted to the back of the queue (low priority).

          The key point that I've missed is the master speed throttler at the trunk of the tree - of course the router's just throwing stuff at the modem as fast as it can so its queues are never full.

          Thankyou for taking the time to reply, and making my kick myse
    • Oh, can Windows do it, too? How does one go about to set that up?

      (All-important disclaimer: I don't use Windows myself, of course, but I might at least be able to help people who do)

      • Ok, I admit, I have no idea how to do it in Windows. I just saw some QoS feature on Windows some time ago, could well be that it's as much a placebo as its firewall feature.

        • Re: (Score:2)

          by kesuki ( 321456 )
          "I have no idea how to do it in Windows"

          Free as in beer, smoothwall express http://www.smoothwall.org/get/vmware.php [smoothwall.org]
          vmware player http://www.vmware.com/products/player/ [vmware.com]

          you do have to play around with your network configuration to route it through smoothwall in the vmware player, and i don't know if you can have vmware player automatically load the smoothwall vm on boot, but there probably is a way.

          a smoothwall VM will need a little cpu resource and a little ram, not as much as a full desktop linux would nee
    • FTA: " With packet prioritization (generally referred to as QoS)... your own video downloads won't need to be stopped and they won't interfere with your VoIP or gaming."

      My Linksys router has a section conveniently called "QoS" Is there any way to adjust these settings so I don't get severe lagging while downloading the latest Ubuntu ISO? (Or something else?)

      Also, I turned on Encryption inside Azureus and my download speed jumped 4 times the rate I was getting. Just a hint for everybody who has Comcast.

  • short answer: (Score:3, Funny)

    by Anonymous Coward on Sunday June 01, 2008 @06:01PM (#23620987)
    Don't download porn while playing WoW.

  • 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...

  • Next on /. (Score:5, Funny)

    by this great guy ( 922511 ) on Sunday June 01, 2008 @06:08PM (#23621051)
    Why BitTorrent causes network bandwidth to be used. And network packets to be sent & received. Really sometimes I wonder.

  • Simpler solution (Score:2, Insightful)

    by Frozen-Solid ( 569348 )
    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

    • Re: (Score:3, Informative)

      by Deltaspectre ( 796409 )
      I have my torrents capped to 1/10 of the advertised connection speeds, but latency still affects me (very visible in ssh sessions to my remote irssi server)

    • Re:Simpler solution (Score:5, Insightful)

      by flerchin ( 179012 ) on Sunday June 01, 2008 @07:11PM (#23621523)
      Read the bloody article. He shows that bittorent traffic capped to 10% of total bandwidth still causes more latency than an http download using 90% of the pipe. The total latency hit is small, but still significant for VOIP or high intensity gaming.

    • Re:Simpler solution (Score:4, Informative)

      by tknd ( 979052 ) on Sunday June 01, 2008 @07:15PM (#23621555)

      That doesn't address the number of open connections issue. Bittorrent clients can often have hundreds of open connections while a browser or a game may only have 1 or 2 connections open. So when the game sends a packet, the router gets it and recognizes that it is connection 99 of 100 open connections. If the router equally prioritizes every packet, then the app that only utilizes a single connection can still wait before being serviced.

      It also doesn't solve the problem of having a roommate who will leave bittorrent on indefinitely.

      The real solution is to come up with a way to analyze packets and determine which packets should have the highest priority. This is called Quality of Service (QoS). Linux and routers based on linux have access to a number of different QoS schemes, but the off the shelf routers may not have good enough hardware to run it. For example I bought a ddwrt compatible router. I dumped the original factory firmware and installed ddwrt. I turned on QoS and put http and other types of traffic at higher priority than the rest. It worked great when the router could handle the traffic. I could let the bittorrent client eat as much as it wanted but when I hit a webpage, the page loaded just as fast. But every once in a while the router would crash or become really slow and inaccessible (can't access it through ssh or http). Turning off QoS alleviated that issue but of course bittorrent would starve out the other apps. In the future I plan on buying a router with a faster cpu so I can leave QoS on.

      • How fast is your router? I want to know beforehand whether or not turning on QoS would make sense on my device.
        • I don't know about his WRT router, but I used to be using HTB shaping on a Pentium II 400 MHz box, without ever seeing it take even so much as a percent of its CPU cycles.

      • If the router equally prioritizes every packet, then the app that only utilizes a single connection can still wait before being serviced.

        While it is possible to allocate bandwidth per connections routers rarely bother, and can't tell the difference between one connection sending 1000 packets, and 1000 connections sending one packet. The problem with TCP is when you receive an ACK packet you typically send a whole window size of data to your peer. If you receive multiple ACK's from different peers in a short space of time, you can easily flood the transmit / receive buffers of the device at your choke point (usually a modem). However if you

  • Wait, wait wait! (Score:2, Insightful)

    by drolli ( 522659 )
    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....

    • Re:Wait, wait wait! (Score:5, Interesting)

      by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Sunday June 01, 2008 @06:45PM (#23621321) Homepage Journal

      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!

      I don't mind traffic shaping [slashdot.org] at all, anywhere. QoS is a good thing, even when the ISPs do it. What I mind a whole awful lot is traffic blocking, ala Comcast.

    • Uh, yeah? (Score:5, Insightful)

      by Anonymous Coward on Sunday June 01, 2008 @06:46PM (#23621327)
      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.

    • Re: (Score:3, Insightful)

      by rossz ( 67331 )
      What ISPs are doing is not traffic shaping. They are doing traffic elimination. I don't have a problem with traffic shaping. It's often necessary to get different things to play nice with each other.

    • Re: (Score:2)

      by dissy ( 172727 )

      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....

      Despite the fact slashdot is not one mind, i still don't believe any sensible person here on slashdot has ever had a problem with traffic shaping.

      Sure, there are a ton of people complaining about liars (IE they do traffic shaping to an extreme and lie about that fact claiming they don't, wasting hours of resources on our end tracking down a problem that is their fault), and when an ISP simply lies on their bills claiming you used more bandwidth than they sold you and is stated you will get in their ads, an

    • Re: (Score:2)

      by nurb432 ( 527695 )
      Not interesting at all.

      If its MY network with MY router, i have the choice of what sort of bandwidth usage will occur.

      When i PAY for bandwidth from my ISP, they shouldn't limit it.

    • Re: (Score:2, Informative)

      by amirulbahr ( 1216502 )
      Injecting TCP RST packets is not traffic shaping. It is sneaky interference with legitimate network access.

  • How clever (Score:4, Funny)

    by blue l0g1c ( 1007517 ) on Sunday June 01, 2008 @06:34PM (#23621237)
    Homebrew traffic shaping. *facepalm*

  • Traffic shaping works but fair-queue works better. (Score:5, Interesting)

    by m.dillon ( 147925 ) on Sunday June 01, 2008 @06:47PM (#23621343) Homepage
    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

    • Re: (Score:2, Informative)

      by wintermute000 ( 928348 )
      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

      • Re:Traffic shaping works but fair-queue works bett (Score:4, Interesting)

        by m.dillon ( 147925 ) on Sunday June 01, 2008 @07:40PM (#23621709) Homepage
        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

    • Re: (Score:2)

      by Barny ( 103770 )
      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 :)

  • Use randomized time rather than even spacing (Score:5, Informative)

    by karl.auerbach ( 157250 ) on Sunday June 01, 2008 @06:50PM (#23621363) Homepage
    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

    • Re: (Score:3, Interesting)

      by dissy ( 172727 )

      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/ [kitchenlab.org]

      Ok, I've been out of network management for a couple years now, but I have never heard of pchar.
      Looking at the URL you gave, there is nearly zero description about the software or how it works or how to use it.
      In addition, i went ahead and downloaded the source hoping there might be some documentation giving a clue about this, and then i noticed:

      As of pchar-1.5, this program is no longer under active development, and no further releases are planned.

      So, to me it seems like you are saying ICMP, which is supported by literally every single device that speaks IP, is disfavored, and the current method is to use a

      • Re:Use randomized time rather than even spacing (Score:4, Informative)

        by karl.auerbach ( 157250 ) on Sunday June 01, 2008 @08:50PM (#23622117) Homepage
        Give pchar a try. Just because it's not being upgraded hardly means that its data is not more accurate than ICMP echo times. Pchar is slow; it emits over 1400 probes per cycle. That's why it can take 15+ minutes to characterize each hop of the path.

        Pchar is derived from Van Jacobson's pathchar; there is a lot of very good and very deep knowledge behind those tools.

        Yes, Ping is better than nothing, and a lot better than things like DNS round trip times. But if you are probing basic connectivity of a single hop the best protocol is to use is ARP.

        But pings, as I mentioned, are often rate limited or slow-path switched or even blocked. And an increasing number of folks don't even reply to 'em. Moreover, they usually don't reveal the fate of large packets to things like MTU constraints or very noisy wireless paths that tend to clobber larger packets (as in bittorrent or HTTP) more often than small ICMP packets.

        By-the-way, a lot of folks have commented on how to use the Linux traffic control system to manage outbound traffic. I commercially build a small box to do this for folks who don't want to mess with "tc" commands.

        But the bigger issue for outgoing links is that the providers don't keep the outbound bandwidth constant; many providers tweek the outbound pipe size fairly rapidly. This makes it quite difficult to maintain the aggregate outbound rate so that the queues build up in the user's box (where the user can do sane management) rather than the provider's box (where the provider does whatever is good for the provider.)
  • http://lartc.org/wondershaper/ [lartc.org]

    Works in Linux since 2002.

    *yawn*
  • What about the upstream being flooded with ACKs?
  • Except, wait for it, almost all p2p clients allow you to throttle your bandwidth anyway.
    • That only works to a point. If you have a single computer you can control the traffic quite well. But if your home network has more then a few computers, all doing different things, PLUS consumer devices such as Apple TV, TiVO, and many other internet-connected devices, the story changes. You will not have control over all the equipment and your only recourse will be active filtering with some sort of queueing mechanic.

      Even a home with only computers under your control may not be entirely under your cont

  • Uplink vs Downlink (Score:4, Informative)

    by m.dillon ( 147925 ) on Sunday June 01, 2008 @07:10PM (#23621521) Homepage
    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
  • Technology for mortals?

    "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, yo

  • Does George Ou have ANY credibility left? (Score:3, Informative)

    by jamrock ( 863246 ) on Sunday June 01, 2008 @07:58PM (#23621807)
    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.
  • 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

    • Re: (Score:2, Insightful)

      by the brown guy ( 1235418 )
      Yeah, but the action that the ISPs take to correct the negative effects caused by millions of people actually using their allotted bandwidth is unfair (and possibly illegal, IANAL and I have no issues w/throttling so haven't been following closely.)
      There is a huge difference between a corporation not giving customers what they have paid for, and the customers using that bandwidth how they see fit.
      Just my 0,02

      • Re: (Score:3, Insightful)

        by thedbp ( 443047 )
        I would say that a network is, by design, a shared interdependancy. Selfish network behavior, regardless of that activity's legality, is a detriment to the entire system, while simultaneously making it harder to maintain, support, and manage.

        Look, I'm not for legislation, but a little common sense will tell you that it simply isn't right for a small minority of the customers to use a massive percentage of available bandwidth, using applications that they themselves say wreak havok on their local network.

        Yo

    • Re:From the Great Geek Philosopher Hypocrates (Score:4, Insightful)

      by chubs730 ( 1095151 ) on Sunday June 01, 2008 @09:48PM (#23622535)
      When are ethical issues not directly derived from self interest? The issue with throttling at an ISP level is receiving the service one pays for. Bandwidth shaping for a personal network, deciding what one would like to do with the service they purchased, is an entirely separate issue.

    • Re: (Score:3, Insightful)

      by evilviper ( 135110 )

      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.

      There's nothing wrong with reasonable traffic shaping. ISPs, however, DON'T want to do that. They want to damn near cut-off Bittorrent traffic enti

    • It's about control. (Score:4, Insightful)

      by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Monday June 02, 2008 @01:10AM (#23623669) Journal
      It's very, very simple:

      The geeks of slashdot acknowledge that P2P use strangles traffic on their LAN, and feel that some modification needs to happen to address this.
      And when we do this, we're doing it to our own LAN. And it affects our own bandwidth, and the bandwidth of any roommates -- who most likely know what's going on, and agree to it. (After all, it's not as though it's going to slow the torrent by much.)

      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.
      Cry "bird"? WTF?

      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.

  • TCP Capture effect (Score:3, Interesting)

    by redelm ( 54142 ) on Sunday June 01, 2008 @09:43PM (#23622507) Homepage
    Doh! This is a long-known effect going by the name "Ethernet Capture Effect", and TCP streams are especially vulnerable. Even moreso on asymmetric links.

    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.

  • A Better Solution (Score:2, Interesting)

    by puddnhead7 ( 576696 )
    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.
    -

  • Bullshit (Score:4, Interesting)

    by XNormal ( 8617 ) on Monday June 02, 2008 @01:56AM (#23623913) Homepage
    Install a bandwidth management tool like cFosSpeed [www.cfos.de] 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.

Slashdot Top Deals

As of next Thursday, UNIX will be flushed in favor of TOPS-10. Please update your programs.

Close