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 - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
