[Bloat] calculating baseline latency properly?

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

I have been fiddling with the latest SFQ patches from eric at 100Mbit.

I'm at the point where what are effectively "quantum effects" are bothering
me, statistically.

At 100Mbit:

I get a baseline latency for ping RTT on my hardware in the range .22 to .48 ms,
call it .32 as an average. Eric gets about 1/3 that, and after testing
it looks like
the majority of the ping latency comes from the cerowrt box for reasons unknown.

There are various tunables for ethtool that have a small effect on the e1000e
side, but not on that side.

Under a 50 iperf load + sfq, on 100Mbit ethernet,
the simultaneous 10ms ping RTTs vary thusly:

BQL = auto. RTT = ~ 2.16 ms
BQL = 4500 bytes =  ~1.2 ms
BQL = 3000 bytes =  ~ .67 ms
BQL = 1500 bytes =  ~.76 ms

I note that these are pretty variable and looking at cdf graphs
makes the most sense over a large sample size, rather than the average.
It also helps when trying to compare sfq vs qfq vs sfqred.

For comparison, PFIFO_FAST (with a txqueuelen of 1000 on both sides),
I get a latency under the same workload of 121ms at all settings for BQL.
(I mean, probably seeing the fractional stuff but it just doesn't matter)

In measuring ping RTT rather than arrival time elsewhere (which I plan
to do with RTP at some point), there's actually two variables in play
send and return time...

So should a RTT latency under load calculation remove the baseline latency
thusly:

latency_improvement =
  (ping_RTT - baseline_ping_rtt) / (new_ping_RTT - baseline_ping_rtt)

factor 344 improvement

OR keep it:

latency_improvement =
  (ping_RTT) / (new_ping_RTT)

factor 180 improvement...

or would there be another way to compensate for it that made sense?

Either way the numbers look grand, and I plan to play with both a
real 10Mbit connection and a simulated 4Mbit one, next. Should
be interesting...

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