Re: [Cake] cake flenter results round 3

[Dave Taht <dave@taht.net>]

All this testing has inspired me to go pick up a cheap ($500!!!) 12 core
Xeon box I found on craigslist, this afternoon. I'm tired of napping
through kernel builds, and needed a space heater.

If anyone else could use a build box and sim station pls send me a ssh key.

I'd like to get some mips/arm/whatever qemu instances up also.

Assuming it proves reliable, I'll converge it with my 10TB nas for
packet captures.

Georgios Amanakis <gamanakis@gmail.com> writes:

> Could you provide an example how to rate limit with netem?

tc qdisc add dev eth0 root netem rate 20mbit

That however creates a tail-drop per-packet queue. You can attach a
sub-qdisc that more closely emulates the real link. Or use HTB. Or
leverage SQM.

Thing is, we've been living in a fantasyland (cake in both directions),
and I'm thinking at least in the downstream direction, attaching a CMTS
or DSLAM emulating tail drop queue would be useful (and depressingly, I
am thinking that ack filtering will lead to even worse bloat on an
un-caked head end).

Your typical Cisco CMTS seemed to be 1000 1.5k packets max.

Arris CMTSes (more common) - I can't tell. My best guess is that they have a
1000-2000 packet limit with GRO enabled, per subscriber, no matter the rate.

Another way to emulate a range of CMTSes is to put a bfifo limit 256k, 512k,
1024k.

DSLAMs have seemed to be in the 64k range.

> What does "slot 4ms 4ms bytes 10k 16" Dave provided do?

This is an attempt to emulate bursty mac (like wifi)'s behaviors.

It will accumulate 4ms worth of packets, then deliver them all in a
bunch. The "interesting" thing to me is the probable effect of the
microburst on cake's deficit scheduler (and new ack filter)

By additionally specifying bytes and packets you can get a max rate out
of it, otherwise it is bound by the speed of qdisc_watchdog_schedule_ns.

I goofed on the line above, it is actually:

slot 4ms 4ms bytes Xk packets Y

slot 4ms # minimum delay for a slot
     4ms # max delay for a slot (it is REALLY hard to reason about
     things with these set for realism[1], so 4ms 4ms is sane for rrul
     testing. A one way test might be 1ms 4ms, with the ack-mostly side
     being 1ms 1ms.)
     bytes 10k # deliver X kbytes per slot. In this case,
           10k * 1000/4ms per slot = ~25Mbit/sec
     packets Y - 802.11n does have a limit (up to 42) 



[1] worse, using 1ms-4ms would create a uniform distribution where the
real distribution is very different and long tailed. (that's work
pending)

>
> George
>
> On Thu, Nov 30, 2017 at 1:27 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>     If you use netem to simulate the physical link, you could test Cake's
>     ingress mode downstream of it.
>
>     - Jonathan Morton
>     
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake