Just wanted to report that this works with my TL-WN723N v3.0. With both
patches applied the adapter is able to saturate my DSL connection.

Brendan MacDonell

On Sun, Apr 26, 2015 at 4:46 PM, Mikhail <mp39...@gmail.com> wrote:
> On 21:22 26-Apr 2015 Mikhail wrote:
>> On 20:20 26-Apr 2015 Stefan Sperling wrote:
>> > On Sun, Apr 26, 2015 at 01:31:17PM +0200, Stefan Sperling wrote:
>> > > On Sun, Apr 19, 2015 at 11:48:32PM +0300, Mikhail wrote:
>> > > > Bellow new version of the patch with above things fixed, also I've 
>> > > > fixed
>> > > > detection of ETV chip in urtwn_attach(), nothing else is changed.
>> > >
>> > > I'm seeing very low data transmission rates with your patch and a
>> > > TP-Link TL-WN725N device. In both 11b and 11g mode, the data rate
>> > > remains very low (less than 100Kbit/s). A different urtwn(4) device
>> > > (with 8188CUS chip) has much better throughput.
>> > >
>> > > Are you seeing this, too?
>> >
>> > The chunk below is wrong for OpenBSD since it sets the intitial transmit
>> > rate to an 11n rate. 0x13 corresponds to the "MCS7" 11n rate,
>> > see linux/drivers/net/wireless/rtlwifi/rtl8188ee/def.h enum 
>> > rtl_desc92c_rate.
>> > The value 11 corresponds to OFDM 54Mbit which is fine for OpenBSD.
>> > We only support 11a/b/g at present.
>> >
>> > --- sys/dev/usb/if_urtwn.c  14 Mar 2015 03:38:49 -0000      1.43
>> > +++ sys/dev/usb/if_urtwn.c  19 Apr 2015 20:27:41 -0000
>> > @@ -1813,7 +2011,10 @@ urtwn_tx(struct urtwn_softc *sc, struct
>> >             txd->txdw4 |= htole32(SM(R92C_TXDW4_RTSRATE, 8));
>> >             txd->txdw5 |= htole32(0x0001ff00);
>> >             /* Send data at OFDM54. */
>> > -           txd->txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11));
>> > +           if (sc->chip & URTWN_CHIP_88E)
>> > +                   txd->txdw5 |= htole32(0x13 & 0x3f);
>> > +           else
>> > +                   txd->txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11));
>> >
>> >     } else {
>> >             txd->txdw1 |= htole32(
>> >
>> > Reverting this change doesn't fix the transmit speed problem, 
>> > unfortunately.
>> >
>> > I wonder if we're making some mistake while setting up the TX descriptor?
>> > There are several differences in the TX descriptors of 88E vs 92C.
>> > For example, 88E has third antenna C available.
>>
>> Hello, in urtwn_init(), in part:
>>
>>         if (sc->chip & URTWN_CHIP_88E)
>>                 urtwn_write_1(sc, R92C_RXDMA_AGG_PG_TH + 1, 4);
>>         else
>>                 urtwn_write_1(sc, R92C_USB_DMA_AGG_TO, 4);
>>
>> comment first 3 lines. It fixes speed problem for me, but I need to
>> understand the issue further, before proposing any solution.
>
> The issue isn't in those lines, but a little bit higher - the driver
> enables usb and dma aggregations, but native linux implementation
> enables only dma and disables usb one.
>
> I've submitted bug report to FreeBSD[1] with a patch, which I see as a
> proper solution:
>
>         urtwn_write_1(sc, R92C_USB_SPECIAL_OPTION,
>             urtwn_read_1(sc, R92C_USB_SPECIAL_OPTION) |
> -           R92C_USB_SPECIAL_OPTION_AGG_EN);
> +           (sc->chip & URTWN_CHIP_88E ?
> +               ~R92C_USB_SPECIAL_OPTION_AGG_EN :
> +                R92C_USB_SPECIAL_OPTION_AGG_EN));
>
> I'd suggest to wait some time for feedback. Testing is welcome, of
> course. Thank you for pointing this out and review in general.
>
> [1] - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199718
>

Reply via email to