Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a78a5526-a278-eaf8-89f6-45c64f44df15@gmail.com>
Date:   Thu, 20 Oct 2022 14:40:04 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.3
Subject: Re: rtl8xxxu: Should it support RTL8188EU?
To:     Jes Sorensen <jes.sorensen@gmail.com>,
        linux-wireless@vger.kernel.org
Cc:     Larry Finger <Larry.Finger@lwfinger.net>
References: <2999b8e8-5706-8bfb-c3a5-5c547ab0a170@gmail.com>
 <012874df-59d4-8973-3dee-48f42208f9fc@gmail.com>
Content-Language: en-US
From:   Bitterblue Smith <rtl8821cerfe2@gmail.com>
In-Reply-To: <012874df-59d4-8973-3dee-48f42208f9fc@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 03/10/2022 16:12, Jes Sorensen wrote:
> On 10/1/22 17:42, Bitterblue Smith wrote:
>> Considering there is a driver for RTL8188EU already in staging,
>> which people have been whittling down, should I put any effort
>> into adding support to rtl8xxxu?
>>
>> It's actually mostly working already [0], but rtl8xxxu doesn't
>> have AP mode, adhoc mode, power saving, etc so it wouldn't be
>> necessarily better than the driver in staging.
>>
>> [0] https://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git/log/drivers/net/wireless/realtek/rtl8xxxu?h=rtl8xxxu-8188eu
> 
> The staging driver is based on the vendor driver which is rather
> dreadful. Given the similarity of the chips, it feels really silly to
> have a second driver for just one chip.
> 
> I see no reason to abandon 8188eu support in rtl8xxxu, but given my
> total lack of time, I am also not able to invest in it.
> 
> Cheers,
> Jes
> 

So now I actually tested r8188eu and it's so bad. Why are people
spending so much time cleaning up a driver that doesn't work well?
With the default module parameters it had 35% packet loss with the
router 3 meters away in the same room. With rtw_power_mgnt=0 the
packet loss is gone but the speed is still disappointing: less than
50 megabits/second download, 65-70 upload, and it's unsteady.

The v5.2.2.4 driver from Larry Finger's repo works much better:
no packet loss and a steady 95 and 85 megabits/second in the same
conditions.

I'll get started then.