Hi Thomas, > -----Message d'origine----- > De : Thomas Pedersen [mailto:thomas@xxxxxxxxxxx] > Envoyé : mardi 16 avril 2013 14:26 > On Mon, Apr 15, 2013 at 3:39 PM, Jean-Pierre Tosoni > <jp.tosoni@xxxxxxxxx> wrote: > > > > The 'device_constant' variable is given the constant value > > '1<<ARITH_SHIFT', which means 1 microsecond if I am correct. > > The airtime is in units of 0.01TU, so a device_constant of 1 is more like > 10us. Then the code is wrong, because the airtime is never converted to 0.01TU ? The comment says 'units of 100kbps' (which is true, I checked in cfg80211_calculate_bitrate()), after that the code applies a 10 factor to convert to units of 1Mbps, so the unit of tx_time is 1us, so device_constant is in us as well. > > > duration for the PPDU header is 20 microseconds in non-HT or 24 us in > > HT, as shown in section 20.3.2 > > > > For the test frame of 8192 bits, say at 300Mbps (MCS15), Bt/r = the > > currently computed airtime is 28 instead of 51, underevaluated by -45% ! > > Since the value accumulates on the mesh path, it may make a big > > difference for the path selection. > > Since O (channel access overhead) is constant, changing it just scales > the metric equally across all links, so I'm not sure what difference > this would make? Two reasons: 1) If we want a path from A to C, and there are two paths A-B-C and A-C, and the bitrates are A-C=100M A-B=300M B-C=300M, we might choose the longer path A-B-C although the headers overhead occur twice and the A-C path is better, even at a slower bitrate. 2) Interoperability. If we want a path from A to C, which can use intermediaries B1 or B2, the datarate through B1 is worse than B2 but metric does not include overhead, and B2 from a non-Linux provider includes overhead, then A might choose the bad path A-B1-C instead of the good path A-B2-C > > Getting device_constant as a function of current protection parameters > and channel type (ie. actual channel access overhead) however, makes > sense. I fully agree ! Jean-Pierre -- 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
