[mosh-devel] Impressed

[Dave Taht]

On Thu, Apr 12, 2012 at 1:14 PM, Dave Taht <dave.taht at gmail.com> wrote:
> On Thu, Apr 12, 2012 at 10:40 AM, Hari Balakrishnan <hari at csail.mit.edu> wrote:

> I'm actually not going to foist this decisionmaking on you, the
> version of netperf now in svn is capable of exercising diffserv,
> socket priority, and tcp algorithms, via remote control, on both sides
> of a connection.
>
> svn co http://www.netperf.org/svn/netperf2/trunk/
>
> build that, and you can exercise these two very different queues under
> saturating loads and observe what happens.

I think I need to clarify this a bit.

Two very different *sets* of queues. To do wifi first:

802.11 has 4 hw queues, VO, VI, BE, and BK. They are defined by the
standards to have different length transmission opportunities and
times to transmit. VO was intended for sub 10ms response times, VI
100ms (and is somewhat misnamed), BE, whatever,
and BK barely scavenging...

Then came along 802.11n which introduced packet aggregation, which
sends up to 64x as many packets in a single transmit window as
previously. I'm of two minds regarding the real utility of the
original hw queue set relative to finding good ways of maximizing
fairness inside of aggregation.

Either way, both the VI and BK queues are underused, and the consensus
on the bloat list was that the first be used more aggressively for
'ant traffic', and the latter be used more aggressively for bk and
torrent like traffic.

As for software queues, the default queue on most systems is something
like pfifo_fast,
which is a basic fifo that respects some tos/diffserv markings.

We've mostly been fiddling with forms of FQ (sfq, qfq) as one way to
reduce latency greatly, see this for an example of what we just pulled
off in Linux 3.3, on wired...

http://www.teklibre.com/~d/bloat/pfifo_fast_vs_sfq_qfq_log.png

(and yes, your stuff works great under sfq, sfqred, and qfq)

but as it turns out, for wifi, the native buffering and retries at
present on most wifi devices is so high as to wipe out most of the
benefit. The white space below the 60ms line on this graph grows in
inverse proportion to the actual transmit rate.

http://www.teklibre.com/~d/bloat/ping_log.ps

So thus, fixing both the software queue to do FQ and queue management,
and finding ways of reducing the inherent buffering on most wireless
devices is on our todo list. In the interim, getting interactive
things into the hardware queues on wifi, somehow, seems to help.

I'd certainly love to see a follow-on to your paper that collects
samples from your widespread base of testers... and join the study
myself.


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net