Hi,
we discussed this in ath5k-devel, but it involves a mac80211 extension, so I'm
bringing it here.
Although Wi-Fi was designed for outdoor use, it's also sometimes used for long
distance outdoor links. However, long distance links require longer ACK
timeout, as packets travel "only" at the speed of light and every kilometer
adds almost 7 microseconds to the roundtrip. So for a driver to be usable
outdoors it has to permit setting ACK timeout from userspace.
Currently this is supported only by out-of-tree Madwifi driver for Atheros
hardware. However, modification of ACK timeout is not an Atheros specific
feature. According to a quick skim over the source code in
drivers/net/wireless, besides ath5k and ath9k it's at least supported by
rt2x00, rtl818x and maybe zd1211.
I think the current hardware support is sufficient for a generic mac80211
solution. The exact interpretation of ACK timeout value is hardware specific,
so I propose a higher level API operating with link distance.
It consists of a new nl80211 parameter:
[NL80211_ATTR_WIPHY_DISTANCE] = { .type = NLA_U32 },
The value of the parameter would be a link distance in meters, so after the
support is added to iw one could set the ACK timeout on a 3km link using:
# iw phy0 set distance 3000
Another required change would be extending cfg80211_ops by functions
set_distance and get_distance. Calculation of appropriate ACK timeout (and in
the case of ath5k, also CTS timeout and slottime) for the distance would be
left to the driver (it's a trivial formula).
I can prepare the patches, if you think these extension would be acceptable.
Suggestions are welcome.
Lukas Turek
On Thu, 2009-11-26 at 21:13 +0100, Lukáš Turek wrote:
> On 26.11.2009 20:25 Johannes Berg wrote:
> > My standard reference was obviously crap -- let's see, 7.3.2.9 is
> > better.
> Yes, I found the table. And now I also noticed the real difference: the slot
> time according to the standard rises in a step of three (which means ACK
> timeout will rise in a step of six). It's quite significant loss of
> precision, but it probably shouldn't make much difference in throughput.
It only affects lost packets anyway, no?
> Anyway, this solutions would be good enough for us if it was accepted. So you
> propose to add parameter NL80211_ATTR_WIPHY_COVERAGE to nl80211 and functions
> set_coverage/get_coverage to cfg80211_ops?
Would that be sufficient? It'd be kinda cool if mac80211 auto-configured
itself if it picked up a beacon that had this information, etc.
johannes
Lukáš Turek a écrit :
> Hi,
>
> we discussed this in ath5k-devel, but it involves a mac80211 extension, so I'm
> bringing it here.
>
> Although Wi-Fi was designed for outdoor use, it's also sometimes used for long
> distance outdoor links. However, long distance links require longer ACK
> timeout, as packets travel "only" at the speed of light and every kilometer
> adds almost 7 microseconds to the roundtrip. So for a driver to be usable
> outdoors it has to permit setting ACK timeout from userspace.
>
> Currently this is supported only by out-of-tree Madwifi driver for Atheros
> hardware. However, modification of ACK timeout is not an Atheros specific
> feature. According to a quick skim over the source code in
> drivers/net/wireless, besides ath5k and ath9k it's at least supported by
> rt2x00, rtl818x and maybe zd1211.
>
> I think the current hardware support is sufficient for a generic mac80211
> solution. The exact interpretation of ACK timeout value is hardware specific,
> so I propose a higher level API operating with link distance.
>
> It consists of a new nl80211 parameter:
> [NL80211_ATTR_WIPHY_DISTANCE] = { .type = NLA_U32 },
>
> The value of the parameter would be a link distance in meters, so after the
> support is added to iw one could set the ACK timeout on a 3km link using:
> # iw phy0 set distance 3000
>
> Another required change would be extending cfg80211_ops by functions
> set_distance and get_distance. Calculation of appropriate ACK timeout (and in
> the case of ath5k, also CTS timeout and slottime) for the distance would be
> left to the driver (it's a trivial formula).
>
> I can prepare the patches, if you think these extension would be acceptable.
> Suggestions are welcome.
>
> Lukas Turek
Hello Lukas,
I think that's a good idea indeed. I think the relationship between ACK
timeout, CTS timeout and slottime and distance should be common (ie
implemented at mac80211 level) since the formula is not so trivial to me
(at least, I've seen several formulas flying around). Then, each driver
needs to convert ACK timeout since the HW registers probably takes into
account some specific MAC hw time.
Moreover, the formula is not the same for 2.4 GHz and 5 GHz.
madwifi had a patch for automatically finding the best ACK timeout,
maybe it could be ported to mac80211 as well.
My 2 cents,
Benoit
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.
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);
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.
Lukas Turek
On Thu, 2009-11-26 at 18:26 +0100, Lukáš Turek wrote:
> It consists of a new nl80211 parameter:
> [NL80211_ATTR_WIPHY_DISTANCE] = { .type = NLA_U32 },
>
> The value of the parameter would be a link distance in meters, so after the
> support is added to iw one could set the ACK timeout on a 3km link using:
> # iw phy0 set distance 3000
>
> Another required change would be extending cfg80211_ops by functions
> set_distance and get_distance. Calculation of appropriate ACK timeout (and in
> the case of ath5k, also CTS timeout and slottime) for the distance would be
> left to the driver (it's a trivial formula).
>
> I can prepare the patches, if you think these extension would be acceptable.
> Suggestions are welcome.
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.
johannes
On 26.11.2009 21:15 Johannes Berg wrote:
> It only affects lost packets anyway, no?
Yes, it does, and 6us is still nothing compared to the transmit duration
(at least 100us).
> Would that be sufficient? It'd be kinda cool if mac80211 auto-configured
> itself if it picked up a beacon that had this information, etc.
We just need an API for setting ACK timeout on long distance point-to-point
links, so this is definitely enough. Unfortunately I can't promise I will
have enough time to implement the automatic configuration, although I see it
would be useful for us too.
Lukas Turek
On 26.11.2009 20:25 Johannes Berg wrote:
> My standard reference was obviously crap -- let's see, 7.3.2.9 is
> better.
Yes, I found the table. And now I also noticed the real difference: the slot
time according to the standard rises in a step of three (which means ACK
timeout will rise in a step of six). It's quite significant loss of
precision, but it probably shouldn't make much difference in throughput.
Anyway, this solutions would be good enough for us if it was accepted. So you
propose to add parameter NL80211_ATTR_WIPHY_COVERAGE to nl80211 and functions
set_coverage/get_coverage to cfg80211_ops?
Lukas Turek
On Thu, Nov 26, 2009 at 6:26 PM, Lukáš Turek <[email protected]> wrote:
> Hi,
>
> we discussed this in ath5k-devel, but it involves a mac80211 extension, so I'm
> bringing it here.
>
> Although Wi-Fi was designed for outdoor use, it's also sometimes used for long
> distance outdoor links. However, long distance links require longer ACK
> timeout, as packets travel "only" at the speed of light and every kilometer
> adds almost 7 microseconds to the roundtrip. So for a driver to be usable
> outdoors it has to permit setting ACK timeout from userspace.
>
> Currently this is supported only by out-of-tree Madwifi driver for Atheros
> hardware. However, modification of ACK timeout is not an Atheros specific
> feature. According to a quick skim over the source code in
> drivers/net/wireless, besides ath5k and ath9k it's at least supported by
> rt2x00, rtl818x and maybe zd1211.
>
> I think the current hardware support is sufficient for a generic mac80211
> solution. The exact interpretation of ACK timeout value is hardware specific,
> so I propose a higher level API operating with link distance.
>
> It consists of a new nl80211 parameter:
> [NL80211_ATTR_WIPHY_DISTANCE] = { .type = NLA_U32 },
Why not instead allow setting ACK timeout directly, e.g. in
milliseconds? (Similar to how signal strength is almost always
returned in dBm, even though the devices themselves use all kinds of
units.)
>
> The value of the parameter would be a link distance in meters, so after the
> support is added to iw one could set the ACK timeout on a 3km link using:
> # iw phy0 set distance 3000
>
> Another required change would be extending cfg80211_ops by functions
> set_distance and get_distance. Calculation of appropriate ACK timeout (and in
> the case of ath5k, also CTS timeout and slottime) for the distance would be
> left to the driver (it's a trivial formula).
>
> I can prepare the patches, if you think these extension would be acceptable.
> Suggestions are welcome.
>
> Lukas Turek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
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
On 26.11.2009 18:32 Gábor Stefanik wrote:
> Why not instead allow setting ACK timeout directly, e.g. in
> milliseconds? (Similar to how signal strength is almost always
> returned in dBm, even though the devices themselves use all kinds of
> units.)
Because the timeout does not depend on the distance only, the calculation
involves at least the transmit duration of an ACK frame, and sometimes more,
depending on the hardware (in one of them I saw they added DIFS to the
timeout, forgot which one).
And on Atheros hardware there are three values that depend on link distance:
ACK timeout, CTS timeout and slot time.
So the equivalent of dBm here is the link distance, not ACK timeout.
Lukas Turek
Benoit PAPILLAULT wrote:
> Hello Lukas,
>
> I think that's a good idea indeed. I think the relationship between ACK
> timeout, CTS timeout and slottime and distance should be common (ie
> implemented at mac80211 level) since the formula is not so trivial to me
> (at least, I've seen several formulas flying around). Then, each driver
> needs to convert ACK timeout since the HW registers probably takes into
> account some specific MAC hw time.
>
> Moreover, the formula is not the same for 2.4 GHz and 5 GHz.
>
> madwifi had a patch for automatically finding the best ACK timeout,
> maybe it could be ported to mac80211 as well.
That patch is a rather ugly hack which involves doing statistics on the
number of retransmissions while changing the distance setting. It has a
tendency to crank up the ack timeout whenever there is some loss or
interference on the link, thereby making the effects of the interference
even worse. I don't think this should be added to mac80211.
At some point, I will try to come up with an implementation for ath9k
which doesn't involve such voodoo, but instead compares the tx timestamp
of some data packets against the rx timestamp of ack packets. I don't
know if this will work, but IMHO it's worth a try.
- Felix
Lukáš Turek <8an@...> writes:
>
> Hi,
>
> we discussed this in ath5k-devel, but it involves a mac80211 extension, so I'm
> bringing it here.
>
> Although Wi-Fi was designed for outdoor use, it's also sometimes used for long
> distance outdoor links. However, long distance links require longer ACK
> timeout, as packets travel "only" at the speed of light and every kilometer
> adds almost 7 microseconds to the roundtrip. So for a driver to be usable
> outdoors it has to permit setting ACK timeout from userspace.
>
> Currently this is supported only by out-of-tree Madwifi driver for Atheros
> hardware. However, modification of ACK timeout is not an Atheros specific
> feature. According to a quick skim over the source code in
> drivers/net/wireless, besides ath5k and ath9k it's at least supported by
> rt2x00, rtl818x and maybe zd1211.
>
> I think the current hardware support is sufficient for a generic mac80211
> solution. The exact interpretation of ACK timeout value is hardware specific,
> so I propose a higher level API operating with link distance.
>
> It consists of a new nl80211 parameter:
> [NL80211_ATTR_WIPHY_DISTANCE] = { .type = NLA_U32 },
>
> The value of the parameter would be a link distance in meters, so after the
> support is added to iw one could set the ACK timeout on a 3km link using:
> # iw phy0 set distance 3000
>
> Another required change would be extending cfg80211_ops by functions
> set_distance and get_distance. Calculation of appropriate ACK timeout (and in
> the case of ath5k, also CTS timeout and slottime) for the distance would be
> left to the driver (it's a trivial formula).
>
> I can prepare the patches, if you think these extension would be acceptable.
> Suggestions are welcome.
>
> Lukas Turek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Hi list,
for more advanced devices such as Atheros multiband multiantenna radios more
additional settings should be available than 80211 driver permits. While talking
about Atheros devices and their use in different environments, not only ACK
timeouts and slottime are concern but also ACK rate, interference mitigation
settins, antenna diversity, antenna mode, calibration interval, LED settings and
more. Therefore, concurrently maintained drivers for Atheros devices
(Madwifi-project, OpenWRT Madwifi driver) are far more usable and tunable in
different environments than ath5k with nl80211. I think, based the ath5k list,
the simplest way would be exporting such device-specific special settings into
procfs or sysfs like Madwifi driver (/proc/sys/dev/wlanX/setting_knob). Then
setting of a special parameter would be simple sysctl or echoing a value into a
file in /proc.. 80211 layer should perform its primary job (e.g. beaconing,
authentication..) and don't care of setting device-specific parameters.
Regards
David Pufer