On Mon, Feb 01, 2016 at 01:57:53PM +0100, Johannes Berg wrote: > On Mon, 2016-02-01 at 13:56 +0100, Sven Eckelmann wrote: > > On Monday 01 February 2016 13:30:37 Johannes Berg wrote: > > > On Mon, 2016-02-01 at 13:24 +0100, Sven Eckelmann wrote: > > > > The change from cur_tp to the function > > > > minstrel_get_tp_avg/minstrel_ht_get_tp_avg changed the unit used > > > > for > > > > the > > > > current throughtput. For example in minstrel_ht the correct > > > > conversion between them would be: > > > > > > > > mrs->cur_tp / 10 == minstrel_ht_get_tp_avg(..). > > > > > > > > This factor 10 must also be included in the calculation of > > > > minstrel_get_expected_throughput and > > > > minstrel_ht_get_expected_throughput to > > > > get similar results as before the change. > > > > > > > > > > 10 is a pretty expensive factor, perhaps that should use 16 > > > instead? > > > > Not really funny but I will change the title. > > Huh? Not sure what you mean. I really meant to change 10 to 16 overall > as far as the factor is concerned, since division by/multiplication > with 16 is far easier in base 2 than by/with 10. Should we first fix the bug introduced by 6a27b2c40b48 and then (with another patch) improve this by changing the factor from 10 to 16 ? The latter is going to be a bigger change because we need to make sure that the value exported via station_info gets still scaled to kbps. Cheers, -- Antonio Quartulli Director of Embedded Software | Open Mesh, Inc.
Attachment:
signature.asc
Description: Digital signature
