Slashdot Mirror

← Back to Domains

Domain: bufferbloat.net

Stories and comments across the archive that link to bufferbloat.net.

Comments · 59

  1. Re:(rolls eyes) by Anonymous Coward · · Score: 0 · on Windows 10 Will Use the Cloud To Free Up Disk Space (arstechnica.com)

    Looks like https://www.bufferbloat.net/pr... would help a lot on your DSL line. It can be used on any openwrt compatible router https://wiki.openwrt.org/doc/h... . Also, a lot of Asus routers compatible with asuswrt-merlin have it https://github.com/RMerl/asusw...
    It will help with games a lot - you will see about 30ms increased latency (time to send one full size packet at 0.5Mbps) when uploading over idle, and up to 50ms of increased latency when downloading (most of the time only about 5ms increased but at peaks it will go higher since your router are not at the correct location for doing QoS in the downstream).

    My FTTH 200Mbps symmetric connection doesn't have good QoS on ISP's end, and without fq_codel/cake I see peak latency of about 100ms when downloading and 50ms when uploading. With it, I see almost no additional latency when uploading and about 1ms when downloading.

    Uh, latency is something you want to *decrease*. 30ms *increased* latency like you cite there would be about twice as bad as what I have now. Little things like this make you sound like you don't really understand what you're talking about, especially when you say them multiple times (so, not a typo).

  2. Re:(rolls eyes) by zekica · · Score: 1 · on Windows 10 Will Use the Cloud To Free Up Disk Space (arstechnica.com)

    Looks like https://www.bufferbloat.net/pr... would help a lot on your DSL line. It can be used on any openwrt compatible router https://wiki.openwrt.org/doc/h... . Also, a lot of Asus routers compatible with asuswrt-merlin have it https://github.com/RMerl/asusw... It will help with games a lot - you will see about 30ms increased latency (time to send one full size packet at 0.5Mbps) when uploading over idle, and up to 50ms of increased latency when downloading (most of the time only about 5ms increased but at peaks it will go higher since your router are not at the correct location for doing QoS in the downstream). My FTTH 200Mbps symmetric connection doesn't have good QoS on ISP's end, and without fq_codel/cake I see peak latency of about 100ms when downloading and 50ms when uploading. With it, I see almost no additional latency when uploading and about 1ms when downloading.

  3. Buffer bloat by FrankHaynes · · Score: 1 · on New York Sues Charter Over Slow Internet Speeds (reuters.com)

    I wonder how much of this can be blamed on Buffer Bloat?

  4. A testimonial by Anonymous Coward · · Score: 1 · on Is Your Internet Connection Free From Bufferbloat? (blogspot.com)

    I've been using CeroWrt (https://www.bufferbloat.net/projects/cerowrt/wiki/ - the initial testbed for all of the bufferbloat work) for at least four years. For the majority of that time I had 1.5Mbps DSL service, but now I'm connected via a 12Mbps ADSL2+ link.

    Prior to the installation of CeroWrt, it was painful for me to attempt to work remotely using an SSH tunnel if someone was watching a show via Netflix, but after setting up CeroWrt everyone was happy (me for not having to yell at my daughter and my daughter for being able to watch Netflix without me yelling).

    With the 12Mbps link, it doesn't seem to be the ingress traffic that causes issues, but the egress traffic (at times, I upload large data sets). Without shaping the outbound traffic, I can see round-trip times in excess of 2 seconds which is just a bit excessive. ;-)

    I recently installed LEDE (https://lede-project.org/) (an OpenWrt (https://openwrt.org/) fork) on a spare router (the same model as the CeroWrt router - WNDR3800) and it is obvious that the software continues to improve.

    It appears that LEDE may be approaching its first stable release (https://forum.lede-project.org/t/criteria-for-first-lede-stable-release/552). If you have a spare router that is supported by LEDE, please consider installing a current build and report any issues found.

    If you would like to learn more, here are a few random links to get you started:

    I feel that the work that Dave (and everyone else that is involved) is so important that I send a few coins his way every month via Patreon. Here's his most recent update: "Where your donations go" (https://www.patreon.com/posts/where-your-go-7564906).

    Dave, a belated Merry Christmas to you and I'm looking forward to a New Year where all of the efforts to tame bufferbloat and make WiFi fast benefit everyone.

  5. A testimonial by Anonymous Coward · · Score: 1 · on Is Your Internet Connection Free From Bufferbloat? (blogspot.com)

    I've been using CeroWrt (https://www.bufferbloat.net/projects/cerowrt/wiki/ - the initial testbed for all of the bufferbloat work) for at least four years. For the majority of that time I had 1.5Mbps DSL service, but now I'm connected via a 12Mbps ADSL2+ link.

    Prior to the installation of CeroWrt, it was painful for me to attempt to work remotely using an SSH tunnel if someone was watching a show via Netflix, but after setting up CeroWrt everyone was happy (me for not having to yell at my daughter and my daughter for being able to watch Netflix without me yelling).

    With the 12Mbps link, it doesn't seem to be the ingress traffic that causes issues, but the egress traffic (at times, I upload large data sets). Without shaping the outbound traffic, I can see round-trip times in excess of 2 seconds which is just a bit excessive. ;-)

    I recently installed LEDE (https://lede-project.org/) (an OpenWrt (https://openwrt.org/) fork) on a spare router (the same model as the CeroWrt router - WNDR3800) and it is obvious that the software continues to improve.

    It appears that LEDE may be approaching its first stable release (https://forum.lede-project.org/t/criteria-for-first-lede-stable-release/552). If you have a spare router that is supported by LEDE, please consider installing a current build and report any issues found.

    If you would like to learn more, here are a few random links to get you started:

    I feel that the work that Dave (and everyone else that is involved) is so important that I send a few coins his way every month via Patreon. Here's his most recent update: "Where your donations go" (https://www.patreon.com/posts/where-your-go-7564906).

    Dave, a belated Merry Christmas to you and I'm looking forward to a New Year where all of the efforts to tame bufferbloat and make WiFi fast benefit everyone.

  6. A testimonial by Anonymous Coward · · Score: 1 · on Is Your Internet Connection Free From Bufferbloat? (blogspot.com)

    I've been using CeroWrt (https://www.bufferbloat.net/projects/cerowrt/wiki/ - the initial testbed for all of the bufferbloat work) for at least four years. For the majority of that time I had 1.5Mbps DSL service, but now I'm connected via a 12Mbps ADSL2+ link.

    Prior to the installation of CeroWrt, it was painful for me to attempt to work remotely using an SSH tunnel if someone was watching a show via Netflix, but after setting up CeroWrt everyone was happy (me for not having to yell at my daughter and my daughter for being able to watch Netflix without me yelling).

    With the 12Mbps link, it doesn't seem to be the ingress traffic that causes issues, but the egress traffic (at times, I upload large data sets). Without shaping the outbound traffic, I can see round-trip times in excess of 2 seconds which is just a bit excessive. ;-)

    I recently installed LEDE (https://lede-project.org/) (an OpenWrt (https://openwrt.org/) fork) on a spare router (the same model as the CeroWrt router - WNDR3800) and it is obvious that the software continues to improve.

    It appears that LEDE may be approaching its first stable release (https://forum.lede-project.org/t/criteria-for-first-lede-stable-release/552). If you have a spare router that is supported by LEDE, please consider installing a current build and report any issues found.

    If you would like to learn more, here are a few random links to get you started:

    I feel that the work that Dave (and everyone else that is involved) is so important that I send a few coins his way every month via Patreon. Here's his most recent update: "Where your donations go" (https://www.patreon.com/posts/where-your-go-7564906).

    Dave, a belated Merry Christmas to you and I'm looking forward to a New Year where all of the efforts to tame bufferbloat and make WiFi fast benefit everyone.

  7. A testimonial by Anonymous Coward · · Score: 1 · on Is Your Internet Connection Free From Bufferbloat? (blogspot.com)

    I've been using CeroWrt (https://www.bufferbloat.net/projects/cerowrt/wiki/ - the initial testbed for all of the bufferbloat work) for at least four years. For the majority of that time I had 1.5Mbps DSL service, but now I'm connected via a 12Mbps ADSL2+ link.

    Prior to the installation of CeroWrt, it was painful for me to attempt to work remotely using an SSH tunnel if someone was watching a show via Netflix, but after setting up CeroWrt everyone was happy (me for not having to yell at my daughter and my daughter for being able to watch Netflix without me yelling).

    With the 12Mbps link, it doesn't seem to be the ingress traffic that causes issues, but the egress traffic (at times, I upload large data sets). Without shaping the outbound traffic, I can see round-trip times in excess of 2 seconds which is just a bit excessive. ;-)

    I recently installed LEDE (https://lede-project.org/) (an OpenWrt (https://openwrt.org/) fork) on a spare router (the same model as the CeroWrt router - WNDR3800) and it is obvious that the software continues to improve.

    It appears that LEDE may be approaching its first stable release (https://forum.lede-project.org/t/criteria-for-first-lede-stable-release/552). If you have a spare router that is supported by LEDE, please consider installing a current build and report any issues found.

    If you would like to learn more, here are a few random links to get you started:

    I feel that the work that Dave (and everyone else that is involved) is so important that I send a few coins his way every month via Patreon. Here's his most recent update: "Where your donations go" (https://www.patreon.com/posts/where-your-go-7564906).

    Dave, a belated Merry Christmas to you and I'm looking forward to a New Year where all of the efforts to tame bufferbloat and make WiFi fast benefit everyone.

  8. A testimonial by Anonymous Coward · · Score: 1 · on Is Your Internet Connection Free From Bufferbloat? (blogspot.com)

    I've been using CeroWrt (https://www.bufferbloat.net/projects/cerowrt/wiki/ - the initial testbed for all of the bufferbloat work) for at least four years. For the majority of that time I had 1.5Mbps DSL service, but now I'm connected via a 12Mbps ADSL2+ link.

    Prior to the installation of CeroWrt, it was painful for me to attempt to work remotely using an SSH tunnel if someone was watching a show via Netflix, but after setting up CeroWrt everyone was happy (me for not having to yell at my daughter and my daughter for being able to watch Netflix without me yelling).

    With the 12Mbps link, it doesn't seem to be the ingress traffic that causes issues, but the egress traffic (at times, I upload large data sets). Without shaping the outbound traffic, I can see round-trip times in excess of 2 seconds which is just a bit excessive. ;-)

    I recently installed LEDE (https://lede-project.org/) (an OpenWrt (https://openwrt.org/) fork) on a spare router (the same model as the CeroWrt router - WNDR3800) and it is obvious that the software continues to improve.

    It appears that LEDE may be approaching its first stable release (https://forum.lede-project.org/t/criteria-for-first-lede-stable-release/552). If you have a spare router that is supported by LEDE, please consider installing a current build and report any issues found.

    If you would like to learn more, here are a few random links to get you started:

    I feel that the work that Dave (and everyone else that is involved) is so important that I send a few coins his way every month via Patreon. Here's his most recent update: "Where your donations go" (https://www.patreon.com/posts/where-your-go-7564906).

    Dave, a belated Merry Christmas to you and I'm looking forward to a New Year where all of the efforts to tame bufferbloat and make WiFi fast benefit everyone.

  9. Re:Nagle algorithm? by mtaht · · Score: 5, Informative · on Is Your Internet Connection Free From Bufferbloat? (blogspot.com)

    It is entirely probable we've been inside our own filter bubble so long (6 years) we cannot properly communicate with first time readers! some folk explaining the problem... the ietf video shows the benefit from fixing it. https://www.bufferbloat.net/pr... showing the extent: http://www.dslreports.com/spee... you have this entirely backwards: "Buffering can reduce latency, especially under heavy load, by better bandwidth utilization, and allowing faster retransmission of dropped packets. If it is slowing things down, then you should fix the buffering rather than eliminating it." You want enough buffering to absorb bursts, but any more just adds latency. Van Jacobson and kathie nichols calls this distinction good queue and bad queue: https://tools.ietf.org/html/dr... Less buffering (and fair queuing) allows for faster retransmission in particular.

  10. I am inclined to put this in the "win" column by mtaht · · Score: 1 · on FCC Requires TP-Link To Support Open Source Router Firmware

    As someone who helped put together one of the biggest filings with the FCC on this matter, with 260+ other people...

    http://fqcodel.bufferbloat.net......

    (in addition to 1300? 1700? filings from other orgs)

    And later met in person with many of the top people there:
    https://www.fcc.gov/ecfs/filin...

    I am inclined to put this result in the "win" column, provisionally.

    June 2 came and went, tp-link's router firmware returned to field upgradable, and other manufacturers did nothing to make flashing other firmwares any harder than it already was. Hopefully, our arguments buttressed the legal case ongoing at the time against tplink (I knew there was one, but not against whom, or over what, I hope to get more details).

    This does not mean the war is won, however. Certainly binary blob firmware that completely controls the radio remains a problem - but progress is being made with the very thin firmware in the 802.11ac mt76 chipset, I am not aware of 5ghz ath9k chips requiring blobs, and other binary only firmwares are improving to support APIs that fq_codel on wifi needs.
    http://blog.cerowrt.org/post/f...

    (Recently a few new *major* chipsets had wifi drivers submitted to the linux kernel, but I haven't looked at what, exactly the firmware controls. The state of most wifi drivers and firmware is thoroughly depressing - and a very smart and fast co-processor is seemingly needed to run at very high rates)

    Five things I learned from this exercise:

    1) If a legalistic solution can be vague, it will be. It then can be spun many ways for many audiences. Read Ed Bernays.
    Still, sometimes what is said publicly, continues to matter, and the FCC has said some very nice things.

    2) The FCC was not the enemy, but a harried organization attempting to fulfill its mandates. As minimally outlined, their problem was the FAA complaining about wifi interference with weather radars. The first solution was overbroad. They have a much better understanding of the roles of open source, third party firmware now - after the keruffle - of the usefulness of user control, better security, and more frequent updates.

    The FCC has WAY bigger problems than linux wifi. The number of wireless capable devices requiring certification and testing is skyrocketing, among other things.

    https://twitter.com/FCC is a good source for the FCC's other concerns.

    3) If you really want attention in D.C., it is a good idea to make a good argument, with a lot of well known people, file it somewhere inside the agency's process, and then issue (buy) a press release, and make the biggest stink you can.
    As it turned out many of the recommendations we made above cannot be implemented inside the FCC's mandates, but the FTCs.

    4) Chipmakers can now no longer hide behind an argument that the FCC will not let them open up their firmware.

    5) The best "proof of the pudding" I can think of would be to push through a new product with much more or entirely open wifi firmware through the FCC processes, using the CRDA library to enforce the rules. Lining up a vendor willing to try that has so far not happened, although I expected a few mt76 chipsets to enter the US by now, I have not been actively watching their RSS feed for progress.

    All in all, honestly, I do think we moved the dial a few notches in the right direction, and I'm going to sleep pretty well tonight.

  11. Re:everyone needs bandwidth controls, not just mob by Bengie · · Score: 1 · on Netflix Admits To Capping Video Streams On Wireless Networks (variety.com)

    http://www.bufferbloat.net/pro...
    Cake is kind of a pseudo-stateless traffic shaper that doesn't need anything configured except the bandwidth. It can evenly distribute bandwidth while keeping latency isolated among flows. It is still being polished, but it is looking really good and promising to be a turn-key simple never worry about bandwidth hogs or latency again. At least on your own bottleneck of an Internet connection. Of course you can't do anything about upstream bottlenecks, but they're hoping to get Cake or similar buffer managers integrated into commercial routers and firewalls. DOCSIS3.1 should support RED, which is similar to CoDel. A big win over a dumb FIFO buffer.

  12. Re:Data cap scam by Agripa · · Score: 1 · on Comcast Expanding Data Cap Locations, Training Reps To Avoid Subject (arstechnica.com)

    You'll love this stateless AQM that does just that. http://www.bufferbloat.net/pro... [bufferbloat.net]

    I know there are a couple of ways to go about it now. AQM also uses the token bucket ideal.

    An ISP could also just provide the bandwidth. Modern telcom grade networking equipment can handle upwards of 500,000 customers in a flat network with fully dedicated bandwidth. Effective a 500,000 port non-blocking switch, except it's a router. An example of equipment. WDM-GPON chassis with 125 ports, each capable of 32 customers and technically 40Gb of full-duplex bandwidth which is 1.25Gb/s per customer. Couple this with 4Tb/s uplinks on the chassis, and you have exactly 1Gb/s per customer the entire way through the chassis.

    This was the argument originally made when the internet was designed with simple flow control and without built in metering; it was cheaper to expand the capacity. That argument fails when the ISPs in a monopoly position protect their legacy industries and rents.

  13. Re:Data cap scam by Bengie · · Score: 1 · on Comcast Expanding Data Cap Locations, Training Reps To Avoid Subject (arstechnica.com)

    A better solution (for the users anyway) is to use traffic shaping on a per stream and per user IP basis. Low bandwidth connections can then be promoted to have low latency. High bandwidth connections can be throttled to a level sufficient to maintain low latency for other traffic. Of course doing this does not allow the provider to make money through penalties.

    You'll love this stateless AQM that does just that. http://www.bufferbloat.net/pro...

    An ISP could also just provide the bandwidth. Modern telcom grade networking equipment can handle upwards of 500,000 customers in a flat network with fully dedicated bandwidth. Effective a 500,000 port non-blocking switch, except it's a router. An example of equipment. WDM-GPON chassis with 125 ports, each capable of 32 customers and technically 40Gb of full-duplex bandwidth which is 1.25Gb/s per customer. Couple this with 4Tb/s uplinks on the chassis, and you have exactly 1Gb/s per customer the entire way through the chassis.

    Of course that uplink needs to go somewhere. That somewhere is a core router. The fastest core router is a 1Pb/s fully non-blocking router that will support up to 1Tb/s ports in the future and dual 500Gb/s ports right now. Take your 4Tb/s of uplink from the chassis and hook that into the core router. Now do that again for up to 125 more chassis, giving you a maximum of 500,000 customers, each with 1Gb/s of dedicated bandwidth. If you didn't notice, I've only allocated 500Tb/s of the 1Pb/s of bandwidth. This allows you to have 500Tb/s of trunk bandwidth to the Internet or peering, not only giving your customers 1Gb/s of core dedicated bandwidth but also upstream dedicated bandwidth, which is crazy overkill.

    The actual cost of this setup is cheaper per customer than DOCSIS3.0 or DSL.

  14. Re:Not a problem by Bengie · · Score: 1 · on Europe's 'Net Neutrality' Could Allow Throttling of Torrents and VPNs (torrentfreak.com)

    AQMs solve the issues people have with QoS and traffic shaping. Instead of doing strict prioritizing, sprase flows get strict priority and heavy flows get bandwidth evenly distributed. http://www.bufferbloat.net/pro...

  15. Trying mainly to get code *maintained* properly by mtaht · · Score: 2 · on FCC's WiFi Rule-Making: Making It Fair For Both Open Source and Proprietary (fcc.gov)

    Dear Bruce:
    In your slashdot posting today you mischaracterized our efforts as attempting to "open source" all routers. (as have multiple other reporters and people)
    I lost sleep for years trying to create a third not "open source" or "closed source" *option* for making society's safety critical source code *public* vs what is currently buried in inauditable binary blobs - and in this letter, tried to shift the core fcc licensing requirements to mandating that the source code at the lowest layers of the network stack be "public, maintained, and regularly updated".

    What license is slapped on this "public" code I totally do not care about - it could mandate you have to sell off your first born child, or slit your throat after reading, for all I care.
    I care only that the sources be public, buildable, maintained and updated.
    http://www.bufferbloat.net/pro...
    Open source and closed source alike have been doing a terrible job of maintenance, and in the embedded market - aside from higher end devices like android and mainline OSes like redhat/ubuntu - are not being updated. That is the *real problem* here that we are trying to solve.
    thx in advance for any efforts you might make to correct your messaging, particularly when talking about our efforts! I have been busting my b**ls to make these points with every reporter I've talked to.
    Aside from that... I think extremely highly of your characterization of the problem's stakeholders, the quality of your letter is even better than ours overall, and your proposed solution quite possibly one that could succeed (although I would shoot for a new licensing regime that made the git committer more responsible, perhaps - it is very worthy of discussion!)
    I am totally willing to discuss restrictions on "how public" things become - and how fast they become so! particularly as I am well aware dismal code quality in many mission and public safety critical pieces of software that is out there. Mandating that all that be made public all at once would induce a terrifying amount of risk to society as a whole, and a staged approach towards making the core blobby bits public would be best.
    ...which is why I have tried to initially limit the call to merely opening up the binary blobs going into wifi, particularly as getting the current 802.11ac trends towards doing so have failed so dismally and wifi far less safety critical than many other things.
    I would dearly like, also, to fix the dsl drivers and firmware worldwide, at least in part, because I strongly suspect quite a lot of it, in light of snowden's revelations, is compromised already, and they just need 50 lines of code or so, and a firmware update, to eliminate the bufferbloat in them - and verify, it really is doing what the authors say in the tin, to the FCC.
    Sincerely,
    Dave Taht
    lead author, the cerowrt project's letter to the fcc
    http://fqcodel.bufferbloat.net...

  16. Trying mainly to get code *maintained* properly by mtaht · · Score: 2 · on FCC's WiFi Rule-Making: Making It Fair For Both Open Source and Proprietary (fcc.gov)

    Dear Bruce:
    In your slashdot posting today you mischaracterized our efforts as attempting to "open source" all routers. (as have multiple other reporters and people)
    I lost sleep for years trying to create a third not "open source" or "closed source" *option* for making society's safety critical source code *public* vs what is currently buried in inauditable binary blobs - and in this letter, tried to shift the core fcc licensing requirements to mandating that the source code at the lowest layers of the network stack be "public, maintained, and regularly updated".

    What license is slapped on this "public" code I totally do not care about - it could mandate you have to sell off your first born child, or slit your throat after reading, for all I care.
    I care only that the sources be public, buildable, maintained and updated.
    http://www.bufferbloat.net/pro...
    Open source and closed source alike have been doing a terrible job of maintenance, and in the embedded market - aside from higher end devices like android and mainline OSes like redhat/ubuntu - are not being updated. That is the *real problem* here that we are trying to solve.
    thx in advance for any efforts you might make to correct your messaging, particularly when talking about our efforts! I have been busting my b**ls to make these points with every reporter I've talked to.
    Aside from that... I think extremely highly of your characterization of the problem's stakeholders, the quality of your letter is even better than ours overall, and your proposed solution quite possibly one that could succeed (although I would shoot for a new licensing regime that made the git committer more responsible, perhaps - it is very worthy of discussion!)
    I am totally willing to discuss restrictions on "how public" things become - and how fast they become so! particularly as I am well aware dismal code quality in many mission and public safety critical pieces of software that is out there. Mandating that all that be made public all at once would induce a terrifying amount of risk to society as a whole, and a staged approach towards making the core blobby bits public would be best.
    ...which is why I have tried to initially limit the call to merely opening up the binary blobs going into wifi, particularly as getting the current 802.11ac trends towards doing so have failed so dismally and wifi far less safety critical than many other things.
    I would dearly like, also, to fix the dsl drivers and firmware worldwide, at least in part, because I strongly suspect quite a lot of it, in light of snowden's revelations, is compromised already, and they just need 50 lines of code or so, and a firmware update, to eliminate the bufferbloat in them - and verify, it really is doing what the authors say in the tin, to the FCC.
    Sincerely,
    Dave Taht
    lead author, the cerowrt project's letter to the fcc
    http://fqcodel.bufferbloat.net...

  17. netperf-wrapper from bufferbloat.net by mtaht · · Score: 1 · on Ask Slashdot: An Accurate Broadband Speed Test?

    Over at bufferbloat.net we have developed several pretty accurate bandwidth and latency measurement tests, that work at speeds up to 40GigE. We wrap the popular with the linux-netdev's "netperf" tool with something that can aggregate and plot the results, called "netperf-wrapper". The most popular test in the suite is called "rrul" which stands for "Realtime Response Under Load", but there are many others in the suite. It has been used to extensively tune several fair queuing and aqm algorithms, notably "fq_codel" which is in cerowrt, openwrt, and many other 3rd party firmwares. Its been used to debug network hardware, wifi, cablemodems, and most recently during the 40GigE batch-bql patchset now entering the linux kernel. Some examples of use to tune a smarter queue management system against modern day cable modems: http://burntchrome.blogspot.co... http://snapon.lab.bufferbloat.... There are also netperf-wrapper results for 40GigE, DSL, and wifi spread around the Internet. The intermediate format netperf-wrapper uses to store its results are in json and parsable by anything, and I keep hoping someone will get around to writing a web interface for the datafiles... Nothing else I've ever seen even comes close to netperf-wrapper for finding good, accurate, long term numbers and multiple forms of anomoly. Pretty much all the web based tests get increasingly inaccurate above 20Mbits. Single threaded TCP tests are bad also as they generally result in someone defeating TCP congestion avoidance in pursuit of the best benchmark numbers. [2] Far more important to the debloaters is not the bandwidth attained but the latency induced while getting it. [1] We maintain several public servers for netperf-wrapper, all connected via a gigE connection to the internet. Thus far we haven't overloaded them (nor advertised them widely), but if you want to give netperf-wrapper a try, and can't set up your own netperf server on the other side, feel free to ping us on the bloat mailing list for some addresses on various continents. [1] A brief rant: Bandwidth != speed. Bandwidth is capacity/interval. Real perceived speed is obtained via low latency. [2] I really hate that all the web network measurement tests don't simultaneously measure ping while running their upload and downloads. IF ONLY those tests would do that, people would start to realize that there is a huge tradeoff between good latency and high bandwidth, and that they are doing their networks in, by optimizing for bandwidth only. Networks engineered for speedtest's current test, *suck* for voip and gaming. I'd like to petition them to at least report ping times under load to the 98th percentile.

  18. Re:+1 for this Post by RR · · Score: 3, Informative · on Ask Slashdot: Life Beyond the WRT54G Series?

    Been looking for another router for almost a year now, and still haven't been convinced of a better one than my WRT54GL

    The WRT54GL is a relic of an ancient time. Most importantly, it's a relic of a time without IPv4 address exhaustion, and without realistic demonstrations of DNS cache poisoning.

    DD-WRT has support for 6in4 and 6to4, but not as much support for IPv6 over PPPoE or DHCP-PD or Sixxs.net AYIYA. I prefer OpenWRT, but I also prefer plain-text configuration via the command line, so I'm weird. OpenWRT officially dropped support for the WRT54GL in the last stable release, 12.09 from April 2013, and it didn't really work right in 10.03, either.

    I've been generally pleased with routers based on the Atheros AR7161, but those are obsolete (only N300 and N600), and not that easy to find. Probably the most famous from that line is the Netgear WNDR3800, the target model for CeroWRT and the EFF Open Wireless Router. 680MHz MIPS24K, 16MB of flash, and 128MB of RAM are so luxurious after the 200MHz BMIPS3300, 16MB RAM, 4MB flash of the WRT54GL.

  19. CeroWRT != Fork by Anonymous Coward · · Score: 0 · on EFF Releases Wireless Router Firmware For Open Access Points

    CeroWRT isn't really a fork as described in the summary, it's more of an experimental branch/playground of sorts, with any relevant development being fed back upstream to OpenWRT. (It tends to rebase on OpenWRT head fairly regularly).

    From the website https://www.bufferbloat.net/projects/cerowrt:

    "CeroWrt is a project built on the OpenWrt firmware to resolve the endemic problems of bufferbloat in home networking today, and to push forward the state of the art of edge networks and routers. Projects include proper IPv6 support, tighter integration with DNSSEC, and most importantly, reducing bufferbloat in both the wired and wireless components of the stack."

  20. Political Absurdism by bill_mcgonigle · · Score: 4, Informative · on FCC Public Comment Period For Net Neutrality Ends Tomorrow, July 15

    Quick, do you vote "yes" or "no" on the Jabberwocky?

    This is the most lucid summary I've seen of the current "debate". Quoting:

    The things that bug me most about the net neutrality debate are:

    0) The whole slow lane/fast lane conception is just wrong. Internet traffic looks nothing like vehicle traffic. On roads, you have only a few lanes to put cars in. On the internet, it's more like you break up the cars and trucks into atoms (packets), mix them all together, pour them through various choke points and reassemble them at their destination no matter in what order they arrive.

    Traffic management at these levels IS needed, and managed at a e2e level by a TCP-friendly protocol (generally), and at a router level by queue management schemes like "Drop Tail". Massive improvements to drop tail, fixing what is known as "bufferbloat" with better "active queue management" (AQM) and packet scheduling schemes (FQ) such as codel, fq_codel, RED, and PIE are being considered by the IETF to better manage congestion, and the net result of these techniques is vastly reduced latency across the chokepoints, vastly improved levels of service for latency sensitive services (such as voice, gaming, and videoconferencing), with only the fattest flows losing some packets and thus slowing down - regardless of who is sending them. Politics doesn't enter into it. Any individual can make their own links better, as can any isp, and vendor.

    Some links:

    http://tools.ietf.org/html/dra...
    https://datatracker.ietf.org/d...
    http://tools.ietf.org/html/dra...
    http://tools.ietf.org/html/dra...

    Furthermore individual packets can be marked by the endpoints to indicate their relative needs. This is called QoS, and the primary technique is "diffserv".

    http://en.wikipedia.org/wiki/D...

    There are plenty of problems with diffserv in general, but they are very different from thinking about "fast or slow" lanes, which are rather difficult to implement compared to any of the techniques noted above. You have to have a database of every ip address you wish to manipulate accessed in real time, on every packet, in order to implement the lanes.

    IF ONLY I could see in the typical network neutrality debater a sane understanding and discussion of simple AQM, packet scheduling, and QoS techniques, I would be extremely comforted in the idea that sane legislation would emerge. But I've been waiting 10 years for that to happen.

    We have tested, and have deployed these algorithms to dramatic reductions in latency and increased throughput on consumer grade hardware, various isps and manufacturers have standardized on various versions, (docsis 3.1 is pie, free.fr uses fq_codel, as does streamboost, as do nearly all the open source routing projects such as openwrt)

    I really wish those debating net neutrality actually try - or at least be aware of - these technical solutions to the congestion problems they seek to solve with legislation. I wouldn't mind at all legal mandates to have aqm on, by default. :)

    It makes a huge difference, on all technologies available today:

    https://www.bufferbloat.net/pr...

    See also the bufferbloat mailing lists.

    1) if we want true neutrality, restrictive rules by the ISPs regarding their customers hosting services of their own have to go - and nobody's been making THAT point, which irks me significantly. In an age where you have, say, gbit fiber to your business, it makes quite a lot of sense from a security

  21. CeroWRT by Porbes · · Score: 1 · on Ask Slashdot: Which Router Firmware For Bandwidth Management?

    CeroWRT could be worth a try. It's focused on traffic management, and has had good reviews in terms of handling throughput intelligently.
    Hardware support is a bit limited though (it's beta and somewhat of a development/research platform, so they're not aiming for multi-platform support).

  22. Re:"What the internet was designed for" by davecb · · Score: 1 · on Killing Net Neutrality Could Be Good For You

    Our experience some time ago building (Sun) gear for theatre display and provisioning was that the protocols were fine, but there were a lot of botches in the software supposedly implementing them (:-))

    The absolute worst was in the software in the projector, but the routers of the day kept getting in our way. Being biased, we preferred to use our own servers for routing, and even there the software wasn't everything we needed. We, and several other people, started off on efforts to do routing differently, some of which now exist (crossbow, software defined networks, etc).

    The same observations have returned as of last year: the "bufferbloat" investigation has exposed exactly what you report: router software over-optimized for throughput and avoidance of buffer overflow. In reality good throughput, minimal overflows and minimal delay/jitter comes from paying attention to latency. There's a discussion at http://tools.ietf.org/id/draft... which I helped a little bit with. As we speak, the bufferbloat community is working on draft RFCs for advanced queue management, the second step towards getting this fixed. There's a meeting scheduled for IETF89, March 2-7, 2014 in London.

    In your specific case, your jitter buffer needs to be bigger in seconds than the ^#&$^&*@!! largest queue that builds up in the path between your source and sink, and the software in between needs to get its queue and therefor buffer use down close to one packet (or packet-train). This is measurable, by the way, and described a couple of places in the discussions at https://lists.bufferbloat.net/...

    I'll claim that in principle it's easy, and in practice a pain in the ass (:-))
    If it weren't being fixed, I'd have exactly the same opinion as you do!

  23. CeroWRT by ad1c · · Score: 1 · on Ask Slashdot: Best Open Source Project For a Router/Wi-Fi Access Point?

    I'm a fan of Cero-WRT: http://www.bufferbloat.net/projects/cerowrt Works well with Netgear routers (a couple of models) and my wireless links stay up for weeks on end.

  24. Some good ideas, some catastrophically bad ideas by RR · · Score: 2 · on Why the Internet Needs Cognitive Protocols

    I find it telling that Liotta (the author from TFA) is not mentioned in any IEEE RFCs, except in RFC 5345 to say that he makes claims with no real-world measurements. But that's just appealing to authority.

    The most troubling part of his proposal, I think, is the elimination of Postel's Law. The Telco-oriented people have been telling the Internet community people all along that what we need is an intelligent network that provides QoS guarantees. The Internet community rejected that, with the result being an Internet that grows in speed and adapts to countless unforeseen applications. Liotta uses the human autonomic nervous system as metaphor, but the fatal flaw is that the human autonomic system has only one brain. The Internet doesn't work with a single controlling entity.

    Likewise, his illustration of the Youtube clip is not entirely accurate. Companies like Google and Netflix are making colocation deals with a bunch of the Internet Service Providers, so that most videos don't have to travel through the backbone, Time Warner Cable aside.

    There are problems with the current Internet and projects to redo the basis of networking, but Liotta's proposals remind me of those fantasy "cities of the future" fiction that I used to read when I was a kid.

  25. Re:Best example of Vaporware I've heard in a while by mellon · · Score: 1 · on New WiFi Protocol Boosts Congested Wireless Network Throughput By 700%

    Actually, the usual reason for a WiFi network to be slow is not a lack of QoS-based routing, but rather bufferbloat, which is what happens when transmit queue buffers in a router or bridge are not tuned to the carrying capacity of the transport. This results in packets being transmitted late, and hence their responses coming late, which fools the TCP congestion control algorithm and causes it to stutter. The result is that although there is sufficient bandwidth on the link, people don't get to use it, because most of the bandwidth is lost either to timeouts or retransmissions.

    It's surprising that NCSU has this weird technique that they've no doubt patented; you could just download a copy of CeroWRT. The linux kernel was patched a while back to support CertWRT's anti-bufferbloat algorithm, but unfortunately right now you also have to apply custom configuration to the router to tune the buffer size to the capacity of your link.

  26. Dedications help by mtaht · · Score: 3, Interesting · on Ask Slashdot: Dedicating Code?

    I lost two friends and my father this year. I dedicated this release of cerowrt ( http://cero2.bufferbloat.net/cerowrt/credits.html ) to them. Most of the machines we have are named after someone that has passed, for example our main build box is named after http://en.wikipedia.org/wiki/John_Huchra It helped a lot to channel them all as we struggled to get the releases out. And, surprisingly, making ice cream, with liquid nitrogen as the coolant, has got to be a healing ritual, around here.

  27. Re:s/slower/laggier/ by Xtifr · · Score: 4, Informative · on Controlling Bufferbloat With Queue Delay

    Yup, and another error in TFS is:

    According to researchers, the cause is persistently full buffers.

    should be "a cause".

    Lame, misleading summaries is par for the course around here, though. But look on the bright side--it helps keep us on our toes, sorting sense from nonsense, and helps us spot the real idiots in the crowd. :)

    At least this one had a link to a fairly reliable source. It wasn't just blog-spam to promote some idiot's misinterpretation of the facts. Might have been nice to also provide a link to bufferbloat.net or Wikipedia on bufferbloat, as well, for background information, but what can you do?

  28. Re:What is bufferbloat? by tayhimself · · Score: 4, Interesting · on Linux 3.3: Making a Dent In Bufferbloat?

    The acm did a great series on bufferbloat
    http://queue.acm.org/detail.cfm?id=2071893 and http://www.bufferbloat.net/projects/bloat/

  29. Re:Bufferbloat by Maow · · Score: 2 · on Linux 3.3 Released

    I've been reading for a year about bufferbloat and all these tools designed to mitigate it but none of the explainations make sense to someone who isn't already a traffic control guru.

    Can someone explain how, if I'm using a typical Linux system as a firewall between my LAN and a cable modem, I should reconfigure that system if I want to not experience bufferbloat?

    Note that I am in no way a network guru / expert, etc. so take my comment with a large dose of salt.

    That said, I don't think there's much you can do in a home environment to mitigate buffer bloat, it's when large ISPs, or other large networks, and backbones interconnect, for the most part.

    I'm not going to say much more at risk of being egregiously wrong. I'll just await someone more knowledgeable to jump in and enlighten us both...

    For anyone reading and is interested in the issue:

    Bufferbloat:

    This problem is caused mainly by router and switch manufacturers making incorrect assumptions about whether to buffer packets or drop them. As a general rule,[which?]} packets should not be buffered for more than a few milliseconds. Any more than this can lead to TCP's congestion-avoidance algorithms breaking, causing problems such as high and variable latency, and choking network bottlenecks for all other flows as the buffer becomes full of the packets of one TCP stream and other packets are then dropped.[4] The buffers then take some time to drain, before the TCP connection ramps back up to speed and then floods the buffers again.

    And a link that may show everything I said to be wrong:

    CeroWrt is a project built on the OpenWrt firmware to resolve the endemic problems of bufferbloat in home networking today, and to push forward the state of the art of edge networks and routers. Projects include proper IPv6 support, tighter integration with DNSSEC, and most importantly, reducing bufferbloat in both the wired and wireless components of the stack....

  30. Re:They invented the debugger! by Mr+Z · · Score: 1 · on A Better Way To Program

    Range checking only gets you so far, and it only catches the most basic bugs. Some languages give you 'assert()' to handle that; others have "programming by contract." Heck, wrap everything in classes that maintain tight control over their invariants and throw exceptions whenever they get cranky. That'll do, right? Not really. It's no silver bullet: Usually, the real bugs--the ones that take the longest to debug and require the deepest thought--result from more complex constraints getting violated, or fundamental thinkos about the problem domain.

    For example, a buffer overflow can be caught with range checking on array indices. Compilers can (and will, if you ask) insert those checks. Typically, fixing the overflow is quick; you just add a simple check prior to filling the buffer. Buffer bloat, on the other hand is an Internet-wide level bug that no amount of range checking, constraint checking or other simple debug techniques will catch for you. It resulted from fundamental thinkos about how to configure the software under the Internet at a grand scale.

    Ok, so that's perhaps an extreme comparison at far opposite ends of the scale. I'm fully aware that the bug "depth" vs. "frequency" distribution probably has a nice 1/x shape, with the shallower bugs occurring far, far more frequently than the deeper bugs. But, at the same time, by very virtue of their frequency and shallowness, they become the most quickly dispatched and easily avoided by a programmer with any experience.

    At least for me, it's as if I've developed an X-ray vision for the really basic bugs. I've been known to walk into a coworker's office and point out "that isn't going to work--you have a stray semicolon after that for() loop" or "there's an off-by-one error there" or other such things. I don't have synesthesia, but still it's almost as if such things show up in a different, if invisible, color or something. Finding and fixing the deeper bugs requires understanding far more of the system at a more thorough level.

  31. Re:Latency by operagost · · Score: 1 · on Ask Slashdot: What Is an Acceptable Broadband Latency?

    ... buffer bloat...

  32. Don't forget about BufferBloat by hebcal · · Score: 1 · on Ask Slashdot: What Is an Acceptable Broadband Latency?

    There are lots of opportunities for network hardware to introduce needless latency:

    Overview:
    http://www.bufferbloat.net/projects/bloat/wiki/Bufferbloat

    Demo:
    http://www.youtube.com/watch?v=npiG7EBzHOU

  33. Re:There are other options for DynDNS only routers by Ethanol · · Score: 1 · on DynDNS Cuts Back Free DNS Options

    In fact, you don't need a dynamic DNS provider at all. My home router (a Netgear WNDR3700, costs about $85) is running CeroWRT, which includes BIND 9, which takes care of dynamic DNS by itself. It also does DNSSEC validation, and serves a dozen or so DNSSEC-signed domains. It's also my web server, IPv6 tunnel endpoint, shell server, and a passel of other things. Current uptime 224 days. Consumer router hardware can do a lot these days.

    (Full disclosure: I'm a BIND 9 author and helped with the CeroWRT port.)

  34. WNDR3700v2 by raul · · Score: 1 · on Ask Slashdot: Best Flash-Friendly Router To Replace Aging WRT54GS?

    Just because for installing this great firmware http://www.bufferbloat.net/projects/cerowrt/wiki/Wiki Kill the bufferfloat, and make your wifi faster and you can play with incredible mesh technologies.

  35. Re:WNDR3700v2 by NitroWolf · · Score: 2 · on Ask Slashdot: DD-WRT Upgrade To 802.11n?

    Check out the WNDR3700v2. The folks doing serious research into home network performance have settled on this unit. Check out the prices on Amazon's refurbished stock - equivalent to what I was paying for 54GL's back in the day. I picked up a new for the office and a refurb for home.

    They have lots of RAM, a decent processor, and dual-band radios. I think it's the 54G for the new decade.

    Since the OP is intending to run DD-WRT on it, it doesn't really matter... but this router is a piece o' crap with the stock firmware. The external drive function has never worked properly, Netgear has known about the bug and never bothered to fix it. The drive(s) will go offline for no explicable reason and require a power cycle. If you aren't using that portion of the router, it's probably fine, but since I purchased this router for my parents house and purchased it explicitly for the extra drive connectivity, I am rather displeased. A quick scan of the Netgear forums reveals that it's a known issue, many people have it, Netgear just doesn't care and won't issue a fix for it.

    Netgear can go piss up a pole.

  36. WNDR3700v2 by bill_mcgonigle · · Score: 2 · on Ask Slashdot: DD-WRT Upgrade To 802.11n?

    Check out the WNDR3700v2. The folks doing serious research into home network performance have settled on this unit. Check out the prices on Amazon's refurbished stock - equivalent to what I was paying for 54GL's back in the day. I picked up a new for the office and a refurb for home.

    They have lots of RAM, a decent processor, and dual-band radios. I think it's the 54G for the new decade.

  37. Ask the vendors about bufferbloat too by rcpitt · · Score: 2 · on Ask Slashdot: 802.11n Bake-Off Test Plans?
    One of the major effects of bufferbloat on wireless is reduced ability to usefully deal with lots of clients connecting to the same AP.

    All the major vendors should be aware of what is going on at www.bufferbloat.net and have something in place to ensure that their products will reflect new updates soonest when things get fixed. This is an ongoing problem that crept up on the internet tech community and there is work in progress to deal with it but it will take time.

    See (for example) Bufferbloat - Dark Buffers in the Internet, 1/20/2011

  38. Fix Bufferbloat first ! by Lennie · · Score: 1 · on Why We Don't Need Gigabit Networks (Yet)

    Speed is not important, latency is. And even more so are the current problems with buffers.

    Here is a presentation on the subject:
    http://www.youtube.com/watch?v=qbIozKVz73g

    Here is the website which deals with the problem and is trying to fix any problems in Linux (drivers and TCP/IP stack):

    http://www.bufferbloat.net/

  39. Bandwidth fixes don't fix latency problems by LinuxParanoid · · Score: 1 · on Vint Cerf Says Fix the Net With More Pipe

    Well, the internet probably does need more bandwidth to support Netflix.

    And I'm not a fan of QoS to get better streaming video either. But is Cerf giving up on fixing the problems with streaming (and any realtime internet work) that we know about, bufferbloat? I heard about that from Jim Gettys (thanks to a tweet from John Carmack). Here's a two-page intro in IEEE magazine or a (more interesting IMHO) PDF slide presentation with nice graphs and there is other advice and documents and code on that bufferbloat website.

    See, the problem with streaming isn't just bandwidth, it's latency, and the variability thereof. We always measure and marketers talk about bandwidth, but only rarely if ever about latency. Thus ISPs don't optimize for it as a rule. The result? You get these occassional 6-second lags and other phenomena and little economic incentive to track them or fix them. (And certain data ISPs are at least mildly incented to look the other way since it protects their VOIP/PSTN revenues).

    How about ISPs actually implement ECN to deal with it? How about router manufacturers design for this (or we all switch to OpenWRT?) How about we techies develop tools to help consumers monitor line quality latency (ping times) over time? How about consumers actually learn to care about latency or we educate them? It's not "too complicated" for consumers to understand; consumers can differentiate between velocity ("what's your car's fastest speed?") and acceleration ("how quickly can it go from 0 to 60?") so I'm sure we could get them to understand bandwidth versus latency. It's just not well measured/monitored right now. (I think we need a better phrase/metric that captures the notion of latency like the "0 to 60" one for cars.)

    If you want to help develop measures of latency, use Bismark (or vote for it in the FCC open apps competition) or come up with an open source ping-until-quit tool that logs timestamps for long time periods and displays the results graphically and/or competitively. Better yet, make a phone app that does this and hooks it to google/whoever's maps and shares the data so fellow consumers can see which areas of the phone company networks really suck. (I'm open to hearing about other tools. I used to use a freeware one but it went payware and the best tools I know of are DSLReports's SmokePing and their other tools.)

    100x greater bandwidth may make recorded video faster, but it won't solve core problems with realtime (streaming or video conferencing) video faster, nor web conferencing, nor necessarily online gaming. I sure as hell don't want the internet's quality to become as lousy as cell phones and that's what'll happen over time if we don't keep ISPs we pay the big bucks to focused on fixing the problems.

        --LP

  40. Bandwidth fixes don't fix latency problems by LinuxParanoid · · Score: 1 · on Vint Cerf Says Fix the Net With More Pipe

    Well, the internet probably does need more bandwidth to support Netflix.

    And I'm not a fan of QoS to get better streaming video either. But is Cerf giving up on fixing the problems with streaming (and any realtime internet work) that we know about, bufferbloat? I heard about that from Jim Gettys (thanks to a tweet from John Carmack). Here's a two-page intro in IEEE magazine or a (more interesting IMHO) PDF slide presentation with nice graphs and there is other advice and documents and code on that bufferbloat website.

    See, the problem with streaming isn't just bandwidth, it's latency, and the variability thereof. We always measure and marketers talk about bandwidth, but only rarely if ever about latency. Thus ISPs don't optimize for it as a rule. The result? You get these occassional 6-second lags and other phenomena and little economic incentive to track them or fix them. (And certain data ISPs are at least mildly incented to look the other way since it protects their VOIP/PSTN revenues).

    How about ISPs actually implement ECN to deal with it? How about router manufacturers design for this (or we all switch to OpenWRT?) How about we techies develop tools to help consumers monitor line quality latency (ping times) over time? How about consumers actually learn to care about latency or we educate them? It's not "too complicated" for consumers to understand; consumers can differentiate between velocity ("what's your car's fastest speed?") and acceleration ("how quickly can it go from 0 to 60?") so I'm sure we could get them to understand bandwidth versus latency. It's just not well measured/monitored right now. (I think we need a better phrase/metric that captures the notion of latency like the "0 to 60" one for cars.)

    If you want to help develop measures of latency, use Bismark (or vote for it in the FCC open apps competition) or come up with an open source ping-until-quit tool that logs timestamps for long time periods and displays the results graphically and/or competitively. Better yet, make a phone app that does this and hooks it to google/whoever's maps and shares the data so fellow consumers can see which areas of the phone company networks really suck. (I'm open to hearing about other tools. I used to use a freeware one but it went payware and the best tools I know of are DSLReports's SmokePing and their other tools.)

    100x greater bandwidth may make recorded video faster, but it won't solve core problems with realtime (streaming or video conferencing) video faster, nor web conferencing, nor necessarily online gaming. I sure as hell don't want the internet's quality to become as lousy as cell phones and that's what'll happen over time if we don't keep ISPs we pay the big bucks to focused on fixing the problems.

        --LP

  41. Bandwidth fixes don't fix latency problems by LinuxParanoid · · Score: 1 · on Vint Cerf Says Fix the Net With More Pipe

    Well, the internet probably does need more bandwidth to support Netflix.

    And I'm not a fan of QoS to get better streaming video either. But is Cerf giving up on fixing the problems with streaming (and any realtime internet work) that we know about, bufferbloat? I heard about that from Jim Gettys (thanks to a tweet from John Carmack). Here's a two-page intro in IEEE magazine or a (more interesting IMHO) PDF slide presentation with nice graphs and there is other advice and documents and code on that bufferbloat website.

    See, the problem with streaming isn't just bandwidth, it's latency, and the variability thereof. We always measure and marketers talk about bandwidth, but only rarely if ever about latency. Thus ISPs don't optimize for it as a rule. The result? You get these occassional 6-second lags and other phenomena and little economic incentive to track them or fix them. (And certain data ISPs are at least mildly incented to look the other way since it protects their VOIP/PSTN revenues).

    How about ISPs actually implement ECN to deal with it? How about router manufacturers design for this (or we all switch to OpenWRT?) How about we techies develop tools to help consumers monitor line quality latency (ping times) over time? How about consumers actually learn to care about latency or we educate them? It's not "too complicated" for consumers to understand; consumers can differentiate between velocity ("what's your car's fastest speed?") and acceleration ("how quickly can it go from 0 to 60?") so I'm sure we could get them to understand bandwidth versus latency. It's just not well measured/monitored right now. (I think we need a better phrase/metric that captures the notion of latency like the "0 to 60" one for cars.)

    If you want to help develop measures of latency, use Bismark (or vote for it in the FCC open apps competition) or come up with an open source ping-until-quit tool that logs timestamps for long time periods and displays the results graphically and/or competitively. Better yet, make a phone app that does this and hooks it to google/whoever's maps and shares the data so fellow consumers can see which areas of the phone company networks really suck. (I'm open to hearing about other tools. I used to use a freeware one but it went payware and the best tools I know of are DSLReports's SmokePing and their other tools.)

    100x greater bandwidth may make recorded video faster, but it won't solve core problems with realtime (streaming or video conferencing) video faster, nor web conferencing, nor necessarily online gaming. I sure as hell don't want the internet's quality to become as lousy as cell phones and that's what'll happen over time if we don't keep ISPs we pay the big bucks to focused on fixing the problems.

        --LP

  42. Bandwidth fixes don't fix latency problems by LinuxParanoid · · Score: 1 · on Vint Cerf Says Fix the Net With More Pipe

    Well, the internet probably does need more bandwidth to support Netflix.

    And I'm not a fan of QoS to get better streaming video either. But is Cerf giving up on fixing the problems with streaming (and any realtime internet work) that we know about, bufferbloat? I heard about that from Jim Gettys (thanks to a tweet from John Carmack). Here's a two-page intro in IEEE magazine or a (more interesting IMHO) PDF slide presentation with nice graphs and there is other advice and documents and code on that bufferbloat website.

    See, the problem with streaming isn't just bandwidth, it's latency, and the variability thereof. We always measure and marketers talk about bandwidth, but only rarely if ever about latency. Thus ISPs don't optimize for it as a rule. The result? You get these occassional 6-second lags and other phenomena and little economic incentive to track them or fix them. (And certain data ISPs are at least mildly incented to look the other way since it protects their VOIP/PSTN revenues).

    How about ISPs actually implement ECN to deal with it? How about router manufacturers design for this (or we all switch to OpenWRT?) How about we techies develop tools to help consumers monitor line quality latency (ping times) over time? How about consumers actually learn to care about latency or we educate them? It's not "too complicated" for consumers to understand; consumers can differentiate between velocity ("what's your car's fastest speed?") and acceleration ("how quickly can it go from 0 to 60?") so I'm sure we could get them to understand bandwidth versus latency. It's just not well measured/monitored right now. (I think we need a better phrase/metric that captures the notion of latency like the "0 to 60" one for cars.)

    If you want to help develop measures of latency, use Bismark (or vote for it in the FCC open apps competition) or come up with an open source ping-until-quit tool that logs timestamps for long time periods and displays the results graphically and/or competitively. Better yet, make a phone app that does this and hooks it to google/whoever's maps and shares the data so fellow consumers can see which areas of the phone company networks really suck. (I'm open to hearing about other tools. I used to use a freeware one but it went payware and the best tools I know of are DSLReports's SmokePing and their other tools.)

    100x greater bandwidth may make recorded video faster, but it won't solve core problems with realtime (streaming or video conferencing) video faster, nor web conferencing, nor necessarily online gaming. I sure as hell don't want the internet's quality to become as lousy as cell phones and that's what'll happen over time if we don't keep ISPs we pay the big bucks to focused on fixing the problems.

        --LP

  43. Re:What about latency? by rcpitt · · Score: 3, Interesting · on Bill Would Make Carriers Publish 4G Data Speeds
    While you're talking about latency - take a look at Bufferbloat and the stuff pertaining to wireless networks in general and cell-data in particular.

    Much of today's cell tower equipment is installed with no queue management turned on - and 100% retry "forever" (or at least a long period of time, longer than the 2 seconds it takes TCP/IP sessions to decide a packet didn't get there and resend, causing cascading congestion) and loads of buffer space to the point where latency is measured in 10s of seconds in some cases.

    A carrier that actually takes advantage of the queue management built into the edge equipment can make their network faster and "feel" faster, and cut down on the actual amount of data they carry - but many (most?) don't have a clue.

    For those interested in diving deeper - take a look at the Bufferbloat mail list and for want of a better one, this post by Jonathan Morton that speaks of 3G

  44. Re:What about latency? by rcpitt · · Score: 3, Interesting · on Bill Would Make Carriers Publish 4G Data Speeds
    While you're talking about latency - take a look at Bufferbloat and the stuff pertaining to wireless networks in general and cell-data in particular.

    Much of today's cell tower equipment is installed with no queue management turned on - and 100% retry "forever" (or at least a long period of time, longer than the 2 seconds it takes TCP/IP sessions to decide a packet didn't get there and resend, causing cascading congestion) and loads of buffer space to the point where latency is measured in 10s of seconds in some cases.

    A carrier that actually takes advantage of the queue management built into the edge equipment can make their network faster and "feel" faster, and cut down on the actual amount of data they carry - but many (most?) don't have a clue.

    For those interested in diving deeper - take a look at the Bufferbloat mail list and for want of a better one, this post by Jonathan Morton that speaks of 3G

  45. Buffer Bloat by seifried · · Score: 1 · on Kyoto Prize Laureate Unsnarls Electronic Networks

    Will it simulate buffer bloat accurately?

  46. Buffer Bloat by seifried · · Score: 2 · on Google Spends $1 Million For Throttling Detection

    A lot of what looks like throttling (especially of latency sensitive applications like VOIP) may actually be buffer bloat - http://www.bufferbloat.net/, so while not malicious the end effect is the same (stuff that should work, doesn't).

  47. Re:Buffer bloat is (not) an illusion... by mtaht · · Score: 1 · on Got (Buffer) Bloat?

    Sort of in answer to both of your questions the bufferbloat.net servers are configured as follows:

    http://www.bufferbloat.net/projects/bloat/wiki/Dogfood_Principle

    trying at every point to make sure http 1.1 actually got used.

    We survived today's slashdotting. Handily.

    That said, your points are well made. SPDY is part of the chromium browser and looks to have some potential.

    In my case, I like the idea of smarter - and eventually sctp-enabled - proxies, especially on wireless hops. See thread at:

    https://lists.bufferbloat.net/pipermail/bloat/2011-February/000068.html

  48. Re:Buffer bloat is (not) an illusion... by mtaht · · Score: 1 · on Got (Buffer) Bloat?

    Sort of in answer to both of your questions the bufferbloat.net servers are configured as follows:

    http://www.bufferbloat.net/projects/bloat/wiki/Dogfood_Principle

    trying at every point to make sure http 1.1 actually got used.

    We survived today's slashdotting. Handily.

    That said, your points are well made. SPDY is part of the chromium browser and looks to have some potential.

    In my case, I like the idea of smarter - and eventually sctp-enabled - proxies, especially on wireless hops. See thread at:

    https://lists.bufferbloat.net/pipermail/bloat/2011-February/000068.html

  49. Re:what it is by mtaht · · Score: 3, Informative · on Got (Buffer) Bloat?

    re:"Interesting problem for dd-wrt"

    Agreed.
    We are throwing efforts at both the mainline kernel and openwrt.
    Openwrt is foundational for dd-wrt and several other (commercial) distributions of Linux on the router. I have a large set of debloated routers already, I'm just awaiting further work on the eBDP algorithm to make better....

    http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_Bloated_LAGN_vs_debloated_WNDR5700

    re: "using pings"
    httpping is a much saner approach than ping, in many cases. Get it from:

    http://www.vanheusden.com/httping/

    re: RED & AQM

    SFB and CHOKEe are in the debloat-testing kernel, as is eBDP.
    RED 93 isn't going to work. nRED may. Experimentation and scripts highly desired. See the bloat and bloat-devel mailing lists for discussions.

    Also:

    http://www.bufferbloat.net/projects/bloat/wiki/Dogfood_Principle

    Also:

    I've seen some VERY interesting behavior with tcp vegas over bloated connections.

    http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_TCP_cubic_vs_TCP_vegas

  50. Re:what it is by mtaht · · Score: 3, Informative · on Got (Buffer) Bloat?

    re:"Interesting problem for dd-wrt"

    Agreed.
    We are throwing efforts at both the mainline kernel and openwrt.
    Openwrt is foundational for dd-wrt and several other (commercial) distributions of Linux on the router. I have a large set of debloated routers already, I'm just awaiting further work on the eBDP algorithm to make better....

    http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_Bloated_LAGN_vs_debloated_WNDR5700

    re: "using pings"
    httpping is a much saner approach than ping, in many cases. Get it from:

    http://www.vanheusden.com/httping/

    re: RED & AQM

    SFB and CHOKEe are in the debloat-testing kernel, as is eBDP.
    RED 93 isn't going to work. nRED may. Experimentation and scripts highly desired. See the bloat and bloat-devel mailing lists for discussions.

    Also:

    http://www.bufferbloat.net/projects/bloat/wiki/Dogfood_Principle

    Also:

    I've seen some VERY interesting behavior with tcp vegas over bloated connections.

    http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_TCP_cubic_vs_TCP_vegas