Dave Täht’s tasks

1) Reducing the unmanaged buffers on the devices I have (all Linux-based) and observing the effects on latency and throughput. This involves a bit of kernel hacking. As kernel hackers go, I’m a little unusual in that usually I work on rt based kernels in the first place, because I do audio editing and production. At the moment, I’m merely using the 2.6.37 kernel as a base, as it’s common between all my devices and the rt patches have frozen at .33.

2) High on my personal list is exploring the inter-relationship between the mq qdisc and the wireless device drivers themselves. Buffering is ok. Unmanaged buffering is not. Wireless has special problems for which most people have been papering over with excessive buffering and retransmit settings, especially on newer devices.

3) Also related to that is playing with the SFB qdisc which seems to have a lot of potential to manage flows at the gateway and laptop level.

4) In the context of real-time, I’d like to be exploring the interaction of HTB and device driver buffering in the context of having smaller quantums for the kernel and device driver(s) to be making their decisions.

5) I’m also helping maintain and upgrade the bufferbloat website, and keep the public conversation(s) on track, and recruiting helpers which is eating far more of my time than I’d like.

RFC Improving DSCP support in Linux


6) Writing articles on describing the mis-understood portions of the IP stack.

I can be found in the #bufferbloat channel(s) on irc.

Save the Mice Diffserv statistics

Dtaht test rig

Experiment - TCP cubic vs TCP vegas

Experiment - Bloated LAGN vs debloated WNDR5700

Improving DSCP support in Linux

Cool TCP/ip animations

  • Random Stuff that I’ll catagorize when I have the time


There’s a rule of thumb for the upper bound in two SIGCOMM-award
papers; I generally use the simple one from the Mathis paper.

bandwidth = (MSS / RTT) * (C / sqrt(loss))

MSS = maximum segment size
RTT = round trip time
C = a constant between 0.87 and 1.31, depending on the ACK strategy
and type of loss
sqrt(loss) = square root of the probability of losing a packet

So, for a given connection, your expected throughput scales linearly
with the size of your packets, and inversely with the RTT and

I have an unverified/untested Python implementation of the equations
at http://www.cs.umd.edu/~jmccann/tcp_tput.py

I wonder how jumbo frames play into bufferbloat. When queues are in
terms of number of packets (not bytes), jumbo frames make the problem
even worse.







Subject: Re: Understanding Bandwidth-Delay Product in Mobile Ad Hoc Networks
X-Boundary: **_

On 01/18/2011 11:27 AM, Dave Täht wrote:
> Don’t know if anyone sent this one to you yet.
> http://cairo.cs.uiuc.edu/publications/papers/elsevier2004-bdp.pdf




> Also, PLUGFEST![]()! Sounds like a good spot to do some testing in
> http://www.networkworld.com/news/2011/030411-ipv6-home-routers.html

No, even better is to educate the UNH Interoperability lab, and have
them test everything.

Dunno if they are competent to test 802.11 full up or not for what we
need; but the task of educating them will make that clear.

See: http://www.iol.unh.edu/ - Jim

Enable ECN on multiple operating systems

irc clients


To edit this page, submit a pull request to the Github repository.
RSS feed

Recent News & Articles

Mar 12, 2017 Wiki page
Make-Wifi-Fast Project
Mar 10, 2017 Wiki page
What Can I Do About Bufferbloat?
Feb 10, 2017 Wiki page
More about Bufferbloat
Dec 27, 2016 Wiki page
RRUL Chart Explanation

Find us elsewhere

Bufferbloat Mailing Lists
#bufferbloat on Twitter
Google+ group
Archived Bufferbloat pages from the Wayback Machine


Comcast Research Innovation Fund
Nlnet Foundation
Shuttleworth Foundation

Bufferbloat Related Projects

Congestion Control Blog
Lede Project (OpenWrt)
Flent Network Test Suite
The Cake shaper

Network Performance Related Resources

Jim Gettys' Blog - The chairman of the Fjord
Toke's Blog - Karlstad University's work on bloat
Voip Users Conference - Weekly Videoconference mostly about voip
Candelatech - A wifi testing company that "gets it".