[Bloat] FQ_Codel lwn draft article review

[Toke Høiland-Jørgensen]

"Paul E. McKenney" <paulmck at linux.vnet.ibm.com> writes:

> I am using these two in a new "Effectiveness of FQ-CoDel" section.
> Chrome can display .svg, and if it becomes a problem, I am sure that
> they can be converted.  Please let me know if some other data would
> make the point better.

If you are just trying to show the "ideal" effectiveness of fq_codel,
two attached graphs are from some old tests we did at the UDS showing a
simple ethernet link between two laptops with a single stream going in
each direction. This is of course by no means a real-world test, but on
the other hand they show a very visible factor ~4 improvement in
latency.

These are the same graphs Dave used in his slides, but also in a 100mbit
version.

> Also, I know what ICMP is, but the UDP variants are new to me.  Could
> you please expand the "EF", "BK", "BE", and "CSS" acronyms?

The UDP ping times are simply roundtrips/second (as measured by netperf)
converted to ping times. The acronyms are diffserv markings, i.e.
EF=expedited forwarding, BK=bulk (CS1 marking), BE=best effort (no
marking). The UDP ping tests tend to not work so well on a loaded link,
however, since netperf stops sending packets after detecting
(excessive(?)) loss. Which is why you see only see the UDP ping times on
the first part of the graph.

The markings are also used on the TCP flows, as seen in the legend for
the up/downloads.

> All sessions were started at T+5, then?

The pings start right away, the transfers start at T+5 seconds. Looks
like the first ~five seconds of transfer is being cut off on those
graphs. I think what happens is that one of the streams (the turquoise
one) starts up faster than the other ones, consuming all the bandwidth
for the first couple of seconds until they adjust to the same level.
These initial values are then scaled off the graph as outlier values. If
you zoom in on the beginning of the graph you can see the turquoise line
coming down from far off the scale in one direction, while the rest come
From off the bottom.

> Please see attached for update including .git directory.

I got a little lost in all the lists of SFQ, but other than that I found
it quite readable. The diagrams of the queuing algorithms are a tad big,
though, I think. :)

When is the article going to be published?

-Toke

-- 
Toke Høiland-Jørgensen
toke at toke.dk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 10m_fq_codel.png
Type: image/png
Size: 79395 bytes
Desc: 10mbit fq_codel
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20121124/0837500b/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 10m_pfifo_fast.png
Type: image/png
Size: 82895 bytes
Desc: 10mbit pfifo_fast
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20121124/0837500b/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 100m_fq_codel.png
Type: image/png
Size: 63717 bytes
Desc: 100mbit fq_codel
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20121124/0837500b/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 100m_pfifo_fast.png
Type: image/png
Size: 68232 bytes
Desc: 100mbit pfifo_fast
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20121124/0837500b/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20121124/0837500b/attachment-0001.pgp>