Re: rc80211-pid: some tuning test results

[Mattias Nissler <mattias.nissler@gmx.de>]

On Sat, 2007-12-08 at 04:42 +0100, Stefano Brivio wrote:
> I run further tests. It looks like I found out the optimal parameters for
> minimizing latency or maximizing throughput or maximizing reliability.

Great. I haven't had much time and probably cannot find more time this
weekend, so I still haven't done much testing.

> 
> Best throughput:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 1       8        11     14       10     12       3      0        1
> 
> Best latency:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 1       8        15     12       8      16       2      1        1
> 
> Best reliability:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 1       8        4      15       8      15       3      0        0
> 
> While a general good setup looks to be:
> 
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 1       8        10     15       9      15       3      0        1
> 
> I would then adopt a system like the one outlined below in order to take
> into account userspace parameters.
> 
> We have Three userspace parameters, ranging from 0 (don't care) to 5
> (care the most). I don't think it makes any sense to have more granularity
> here.

Why wouldn't you let userspace set the raw parameters directly? The
complicated scheme you propose prevents us to tell users/testers to
"change the X parameter to see it gives better Y results". If you give
access to the raw parameters, people can still tweak and tune them if
the rate control fails for special situations (e.g. hardware that cannot
report whether a frame was only retried or totally failed, special noise
situations, whatever).

Furthermore, you can still have the simplified scheme by providing a
userspace tool (maybe even add it to iw, once we have an interface) that
takes the input, calculates the raw parameters as below and writes the
results to the kernel.

Bottom line: This thing complicates the kernel, makes the thing less
understandable for people who now what a PID controller is, complicates
future tweaking and tuning of the (default) parameters and moreover
could also be implemented in userspace. So my vote is against it.

> 
> Starting from:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 1       8        10     15       9      15       3      0        1
> 
> We add:
> For every threshold point:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 		+0.2	-0.2	+0.2	-0.6
> 
> latency points:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 		+1	-0.6	-0.2	+0.2	-0.2	+0.2
> 
> reliability points:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 		-1.2		-0.2				-0.2
> 
> I'll now try to implement this sorting out the fixed point calculation
> issues.

I've done a lot of code cleaning, maybe you want to base your patches on
that. There's more to come, but I'll send them so you have something to
start.

Mattias