Re: [Cake] [RFC PATCH 4/5] q_netem: support delivering packets in delayed time slots

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

On Sat, Nov 18, 2017 at 5:18 AM, Pete Heist <peteheist@gmail.com> wrote:
>
> On Nov 17, 2017, at 11:55 PM,dave.taht@gmail.com wrote:
>
>
> Slotting is a crude approximation of the behaviors of shared media such
> as cable, wifi, and LTE, which gather up a bunch of packets within a
> varying delay window and deliver them, relative to that, nearly all at
> once.
>
>
> Nice…

Meh. It really is "crude", and I keeping kicking about ways to somehow
emulate half (or less) duplex, variable rates around a mean, mcast,
etc.

it IS very nice to have a rate limiter that actually behaves a bit
more like wifi, and I hope to also add the new ack fitering stuff to
it.

>
> One of the things I also notice in my LAN tests is latencies for different
> flows staying at more or less fixed (and different) positions relative to
> the mean in flent results. Those positions, and the mean, can change with
> each test run. Do you think this could result from the hashing to different
> hardware queues (four in my case) changing between test runs?

yes if you are using bql probably. Is it sch_mq on top?

> And is it
> worth trying to simulate this effect, or not really?

Dunno. There are a couple ways to turn it off.

> Just for info, in my case (Intel i210) the hashing is documented starting on
> page 254 of the specs:
> https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/i210-ethernet-controller-datasheet.pdf
> (7.1.2.10.1 RSS Hash Function). For TCP/UDP it uses source and destination
> addresses and ports. I suppose this could be smoothed over in testing by
> using a spread of ports for the latency test.



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619