On Thu, 2009-11-26 at 20:14 +0100, Lukáš Turek wrote: > On 26.11.2009 19:18 Johannes Berg wrote: > > I discussed this with Alina a while back (in private, she didn't want to > > discuss in English) and we came to the conclusion that set_coverage() > > should be done like 802.11-2007 17.3.8.6 specifies for 5ghz, but could > > be done for 2.4ghz as well. Thoughts? It would also allow us to actually > > advertise that to compatible clients. My standard reference was obviously crap -- let's see, 7.3.2.9 is better. > If I understand the standard correctly, it means the slottime should be > (9 + propagation_delay), which equals (9 + distance / 300). And that's > basically the same as the formula from Madwifi's athctrl I wanted to use: > int slottime = 9 + (distance / 300) + ((distance % 300) ? 1 : 0); That formula is a weird way of rounding up ... > The main difference is that the coverage classes have an upper limit under > 28km, but I don't see the point in artifically limiting maximum link distance > (30km link could be done with big enough antennas). > > And I would prefer if the userspace API operated with distance rather than > coverage classes, because it allows the user to set it correctly without > reading a thousand page document. The coverage class could be then calculated > for use in beacons as you proposed. Of course, in this case we would be > constrained by the maximum coverage class in the standard. No, you want the _user_ API to be operated with distance, not the _userspace_ API. Conversion like that ought to be done in iw, not the kernel. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
