Re: [Cerowrt-devel] tc-stab versus htb on ADSL 8000/700

[Dave Taht <dave.taht@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3809 bytes --]

0) What cero version is this? I have a slightle optimization for codel in
3.10.6 that I'd hoped would improve < 4mbit behavior... basically it turns
off maxpacket (and was discussed earlier this month on the codel list) as
not being useful outside of the ns2 environment.

1) I kind of prefer graphs get stuck on a website somewhere, rather than
email. Having to approve big postings manually adds to the 10 spams I have
to deal with per day, per list.

We would certainly like to add an "upload this test" feature to rrul one
day, that captures more data about the user's configuration and the test
data (from both sides!), but that project and servers remain unfunded, and
toke's really busy with his masters thesis...

2) Test #1 at T+48 or so appears to have a glitch - either caused by local
traffic on the link or something else. The long diagonal lines that you see
are bugs in the python-matplotlib library, they are fixed in ubuntu 13.4
and latest versions of arch. The choppy resolution of the second graph in
each chart is due to the sample interval being kind of small relative to
the bandwidth and the RTT. That's sort of fixable, but it's readable
without it....

Moving to what I see here, you are approximately 50ms (?) or so from the
icei.org server which is located on the east coast of the US (NJ, in
linode's co-location facility) (services on this box are graciously donated
by the icei organization that has been working in the background to help
out in many ways)

The black line is an average of 4 streams in the first and second graphs in
each chart. So you can multiply by 4 to get a rough estimate of actual
bandwidth on this link, but you do have to factor in the measurement
streams (graph 3), and the overhead of acks in each direction (which is
usually 66 bytes every other packet for ipv4), which are hard to measure.
So you are showing 6Mbit of raw bandwidth down, and about 480 up. Factoring
in the ack overhead of the the down, into the up, gets pretty close to your
set limit of 700. You experienced packet loss at time T+6 (not unusual)
that killed the non-ping measurement flows. (some day in the future we will
add one way ping measurements and NOT stop measuring after the first loss)

(There are multiple other plot types. do a --list-plots rrul. You can
generate a new plot on the same data by taking the *json.gz file and
supplying a different output filename (-o filename.svg) and plot type (-p
totals)

I regard the cdf plots as the most useful, but ALWAYS check this main graph
type to see glitches. Otherwise a cdf can be very misleading.)

So in this test latency spikes by about 100ms. Why does it do that? Well,
you have to fit 6k bytes (4 1500 byte flows), + 122 bytes (2 acks), + 65
bytes (ping) into the queues, and at 700kb/second that queue is far less
than the default 5ms target we start with. a 1500 byte packet takes 13ms to
transmit at 1Mbit, so we are ending up here with sufficient "standing
queue" to

Frankly, it should, eventually, achieve a tcp window size that will reduce
the latency to something lower than 100ms, but it obviously isn't.
nfq_codel is "tighter", but who knows, we're still in very early days of
trying to optimize for these bandwidths, and, like I said, I just killed
the maxpacket thing which might help some. A longer test (-l 300) at this
rtt) might be more revealing.

Clear as mud?



On Wed, Aug 14, 2013 at 2:28 PM, Fred Stratton <fredstratton@imap.cc> wrote:

>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>


-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #1.2: Type: text/html, Size: 4796 bytes --]

[-- Attachment #2: fq_simplest_htb_8000_700a.png --]
[-- Type: image/png, Size: 241826 bytes --]

[-- Attachment #3: fq_simplest_tcstab_8000_700a.png --]
[-- Type: image/png, Size: 200986 bytes --]