Hi,
I've been reported a problem with RTL8187 working only at very close ranges
(4-5m) in Linux while the same hardware works at much higher distances in
Windows. Investigating the problem, I found that it's caused by the mac80211
rate control incrementing the bit rate to 54M and never going down because
the fail counter stays at zero. What would be a good way to check
transmission retries or failures in the RTL8187 to prevent this problem? Is
it possible to have a retry count sent to the tx callback so
status->retry_count could be set accordingly?
On Tuesday 06 November 2007 19:39:11 Claudio Matsuoka wrote:
> Yes, I thought so. I checked the Realtek site and these specs are not
> published there, are they restricted for some reason or can I have a look
> at them?
>
Restricted, but you can find the specs for the 8186 floating around on the net
which tells you a bit about the registers. Doesn't tell you anything about
the rx/tx path of the usb variant, which is a bit inferior to the rx/tx path
of the pci chips. There's no easy way to do tx ack reporting on the rtl8187.
The only solutions that could work involve some polling or a different rate
control algorithm.
-Michael Wu
I botched Michael's email address -- please not that when composing
your replies (or reply to this message instead)...
John
On Tue, Nov 06, 2007 at 11:41:48AM -0500, John W. Linville wrote:
> On Tue, Nov 06, 2007 at 01:23:16PM -0200, Claudio Matsuoka wrote:
>
> > I've been reported a problem with RTL8187 working only at very close ranges
> > (4-5m) in Linux while the same hardware works at much higher distances in
> > Windows. Investigating the problem, I found that it's caused by the mac80211
> > rate control incrementing the bit rate to 54M and never going down because
> > the fail counter stays at zero. What would be a good way to check
> > transmission retries or failures in the RTL8187 to prevent this problem? Is
> > it possible to have a retry count sent to the tx callback so
> > status->retry_count could be set accordingly?
>
> I think you are right -- it looks like rtl8187 never sets
> excessive_retries for transmit status. I don't see anything obvious
> in the specs that would give us an actual indication of that either,
> which probably explains why it is missing.
>
> The zd1211rw(-mac80211) driver(s) have a mechanism for matching-up
> received ACKs with transmitted frames so that they can synthesize the
> required excessive_retries data. Probably rtl8186 needs something
> similar. Maybe this would even be worth generalizing?
>
> John
> --
> John W. Linville
> [email protected]
--
John W. Linville
[email protected]
On Wednesday 07 November 2007 12:20:43 Johannes Berg wrote:
> > There's no easy way to do tx ack reporting on the rtl8187.
>
> This also means it doesn't show you outgoing frames on a monitor. We
> really need to find a solution here that takes into account our current
> use of tx status reports for outgoing frame monitor as well as rate
> control.
That would be important since the current situation for users of rtl8187 and
possibly other chips with similar problems is to be limited by default to a
very short range, or manually set bitrates (or resort to some ugly hack to do
that). By the way, setting the bitrate back to "auto" isn't working as well
in the rtl8187 once you switch to fixed, but given the current situation it's
more a feature than a bug :)
On Tuesday 06 November 2007 11:41:48 John W. Linville wrote:
> The zd1211rw(-mac80211) driver(s) have a mechanism for matching-up
> received ACKs with transmitted frames so that they can synthesize the
> required excessive_retries data. Probably rtl8186 needs something
> similar. Maybe this would even be worth generalizing?
>
Nope, not that easy. zd1211 has an interrupt for failed TX which is why that
works.
rtl8186 is a SoC. I think you mean rtl8185 or rtl8180, but they do tx
reporting fine. It's just the usb variant which has issues.
-Michael Wu
> There's no easy way to do tx ack reporting on the rtl8187.
This also means it doesn't show you outgoing frames on a monitor. We
really need to find a solution here that takes into account our current
use of tx status reports for outgoing frame monitor as well as rate
control.
At the higher network speeds of 802.11n equipment we'll not want to do
this anyway.
Since hostapd needs to know whether the packets it sent were acked,
we'll have to go back to using IEEE80211_TXCTL_REQ_TX_STATUS for those
injected frames.
Then we need to decide whether we want to report all outgoing frames on
monitor interfaces or only those where the hardware was able to provide
a status report. The latter would be sufficient for hostapd, of course.
Finally, we need to create a new hardware flag that determines whether
the driver will report status for all frames or not, this influences the
possible rate control algorithm choices. Of course we still need to
write rate control algorithms that are able to work with synthesized
information...
johannes
On Tue, Nov 06, 2007 at 01:23:16PM -0200, Claudio Matsuoka wrote:
> I've been reported a problem with RTL8187 working only at very close ranges
> (4-5m) in Linux while the same hardware works at much higher distances in
> Windows. Investigating the problem, I found that it's caused by the mac80211
> rate control incrementing the bit rate to 54M and never going down because
> the fail counter stays at zero. What would be a good way to check
> transmission retries or failures in the RTL8187 to prevent this problem? Is
> it possible to have a retry count sent to the tx callback so
> status->retry_count could be set accordingly?
I think you are right -- it looks like rtl8187 never sets
excessive_retries for transmit status. I don't see anything obvious
in the specs that would give us an actual indication of that either,
which probably explains why it is missing.
The zd1211rw(-mac80211) driver(s) have a mechanism for matching-up
received ACKs with transmitted frames so that they can synthesize the
required excessive_retries data. Probably rtl8186 needs something
similar. Maybe this would even be worth generalizing?
John
--
John W. Linville
[email protected]
On Tuesday 06 November 2007 14:41:48 John W. Linville wrote:
> I think you are right -- it looks like rtl8187 never sets
> excessive_retries for transmit status. I don't see anything obvious
> in the specs that would give us an actual indication of that either,
> which probably explains why it is missing.
Yes, I thought so. I checked the Realtek site and these specs are not
published there, are they restricted for some reason or can I have a look at
them?