macbroadcast´s blog

Beating the speed of light on the web
October 9, 2011, 10:31 am
Filed under: Decentralization, DNS, freedombox, globalchange, Hacking, howto, ipv6, linux | Tags: , ,

by Dave Täht

I started writing this piece this morning to talk about two things – bandwidth – which is pretty well understood – and latency, which is not – in the context of getting better performance out of humanity’s synergistic relationship with web based applications.
The problem is the speed of light!

“For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.” 

                                                                     –Richard Feynman

Yesterday, I accidentally introduced a triangular routing situation on my network, which effectively put me on the moon, in time and space, relative to google. I was a good 3+ seconds away from their servers, where normally I’m about 70ms away.

It made clear the source of the latency problems I’d seen while travelling in Australia and in Nicaragua, where google’s servers (in 2008) were over 300ms and 170ms RTT, respectively.

Everybody outside the USA notices the KER… CHUNK of time they lose between a click to web access… and even in the USA this sort of latency is a problem.

Programmers try really, really hard to mask latency – web browsers spawn threads that do DNS lookups asynchronously, they make connections to multiple sites simultaneously, and they try to render as much of the page as possible as it is still streaming, and for all that, the best most web sites can do is deliver their content in a little over half a second, and most are adding additional layers of redirects and graphical gunk that make matters worse – and all they are doing, is trying to mask the latency that is unavoidable. Read more


It´s the bufferbloat stupid
August 25, 2011, 8:54 pm
Filed under: Decentralization, globalchange, Hacking, howto, ipv6 | Tags: , , , , ,

CeroWrt – Debloating

I don´t know if you heard about Bufferbloat yet, i posted a google tech talk a few weeks ago regarding this issue.

I would recomment watching it, to get a brief overview of what it is about. A few days before i mentioned that there is a interesting project called  CeroWrt , whitch claims to work on this network buffer issues.


Bufferbloat is a widespread problem present throughout the Internet, “end-to-end.” Debloating is a “work in progress” industry wide and will take years. Ultimately, all buffering/queuing in operating systems needs to be carefully managed and be automatically adaptive to the data transfer rates. All network routers (and operating systems!) should be running with AQM (e.g. algorithms such as RED) including home routers: unfortunately, existing algorithms such as RED are unlikely to work correctly in today’s home network environment.

CeroWrt is the test platform for improved AQM algorithms. To achieve ultimate latencies under load across the high bandwidth variation of 802.11 and broadband, new AQM algorithms need testing in addition to more complex changes in internal buffering; these will take time and therefore debloating will be a work in progress for an extended period.

In the upstream direction, the bottleneck link may be adjacent to your home devices (e.g. your laptop on wireless), and in your operating system, outside of our control; you may see problems therefore copying from your home device upstream to the Internet and/or your home file server. Unfortunately, TCP acks can be stalled behind packets queued in a particular direction, so bufferbloat in one direction can result in bad performance (poor latency) in the other direction. If you run Linux, you can help with debloating by working with those working on the debloat-testing work going on on On other operating systems, you should contact your operating system vendor and complain. Be gentle (but insistent), however: before 2011, bufferbloat was not understood to be a general problem, and it will take time to overcome.

Note that bufferbloat only occurs in the device just before the bottleneck in a path. A common strategy when fixes for bufferbloat are not available for the devices either side of a bottleneck, therefore, is to try to arrange to move the bottleneck from a device which is badly bloated to one which is not: e.g. you might arrange to ensure that your wireless bandwidth is always bigger than your broadband bandwidth (and using bandwidth shaping and QoS to avoid the consequences of bufferbloat in that hop as best you can).


Check out daves blog


Bufferbloat: Dark Buffers in the Internet Download PDF version of this article

by Jim Gettys, Kathleen Nichols | November 29, 2011

Topic: Networks