RTL8187 rate control problems

RTL8187 rate control problems

[Claudio Matsuoka]

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?   

Re: RTL8187 rate control problems

[John W. Linville]

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
linville@tuxdriver.com

Re: RTL8187 rate control problems

[John W. Linville]

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
> linville@tuxdriver.com

-- 
John W. Linville
linville@tuxdriver.com

Re: RTL8187 rate control problems

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: RTL8187 rate control problems

[Claudio Matsuoka]

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?

Re: RTL8187 rate control problems

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: RTL8187 rate control problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]


> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: RTL8187 rate control problems

[Claudio Matsuoka]

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 :)