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

[Pete Heist <peteheist@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]


> 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…

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? And is it worth trying to simulate this effect, or not really?

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 <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.

[-- Attachment #2: Type: text/html, Size: 1853 bytes --]