It won't. You've beaten this horse to death (and then some). It's time to accept reality and either put up with the speeds you've got now, or do what you've been advised multiple times and buy new hardware.
1 Like
There are no other options, seems you've been told this multiple times.
By using our time in what we all agree is fruitless?
Just buy a cheap router and turn it into a dumb ap. You don't even need to flash it with OpenWrt because it is just a switch with radios.
Just make sure it has WPA3.
dump AP would still give the issue of having no ethernet cable
So?
It would still have better reception and throughput than what you have now.
And stop coming up with problems for answers:
Winners have answers for problems and losers have problems for answers.
so there would be no connection
dump ap needs an ethernet cable for the connection
this is getting out of hand
can a moderator restore this to 11PM last night UK time
and remove the solution
@psherman is a mod.
You really are annoying:
Then make it a wireless bridge.
yes and as far as I know they marked it as solved
Thank you for that, I know I am, because I think I am neurodivergent
thats what I am trying to do here but relayd will half the speed
Because your device sucks and needs to be replaced.
Not saying you suck.
You cannot light a football pitch with a candle.
I was told WDS might help yesterday by @brada4
CPU is not at 100%
more like 10-20% with a spike at 50%
There are a lot of maybes in brada's post.
Go into your wireless adapter, choose config at the top DDgo anything that is configurable and you will land on a page with the optimal wifi settings; make sure all of them are optimized.
I don't think it will help but at least you know you tried everything.
Here are some YT videos for optimizations.
List of videos is on the right. Just ignore they are netgear centric.
0% in interrupts is not credible under load.
If your link rate is 400Mbps obvious you get 200 after reflecting via acess point. Why not 80MHz? Then it will be 866/2mbps.
Rig fast.com test to run for 5 minutes and run waveform latency tests after in each case
- wwan to wired
- wwan to AP in same 5GHz
- wwan to AP in 2.4GHz
- wwan to AP with offload ...
Then switch uplink to WDS and re-run tests
Did it go worse? Like megabits less or milliseconds more?
@brada4 is saying you have to saturate the throughput while you look at the graph.
Don't argue, configure and re-test under load.
I was using a iPhone for the speed testing
this PC is wired because its wireless antennas are internal and its a desktop PC
the antennas are too close to metal blocking part of the signal
anyway
I wasn't
and that CPU usage was with the connection being used by smart home devices on 2.4GHz
connect my iPhone to the 5GHz and its 40-50%
This is 80MHz
DFS 120 becuse non DFS is terrible
I have been testing WDS on my RE200 but setting the STA to WDS, causing it to keep connecting and disconnecting
That was proactive advice and not and admonishment.
You have some YT vids to watch and some configs to tweak.
If that does not work, the topic is sollved by identifying you are hardware limited.
I did and found nothing useful
how am I hardware limited with 50% CPU Usage
So you are being kicked by active radar. 200Mbps is expected result with 40MHz across extender.....
I have had that said to me before it might be true actually, but wouldn't the log says radar hit
Mon Oct 9 22:51:00 2023 kern.info kernel: [ 2577.056424] phy1-sta0: deauthenticating from # by local choice (Reason: 3=DEAUTH_LEAVING)
Mon Oct 9 22:51:00 2023 daemon.notice wpa_supplicant[1096]: phy1-sta0: CTRL-EVENT-DISCONNECTED bssid=# reason=3 locally_generated=1
Mon Oct 9 22:51:00 2023 daemon.notice wpa_supplicant[1096]: BSSID # ignore list count incremented to 2, ignoring for 10 seconds
Mon Oct 9 22:51:00 2023 daemon.notice wpa_supplicant[1096]: phy1-sta0: CTRL-EVENT-DSCP-POLICY clear_all
Mon Oct 9 22:51:03 2023 daemon.notice wpa_supplicant[1096]: phy1-sta0: SME: Trying to authenticate with # (SSID='#' freq=5600 MHz)
Mon Oct 9 22:51:03 2023 kern.info kernel: [ 2580.068667] phy1-sta0: authenticate with #
Mon Oct 9 22:51:03 2023 kern.info kernel: [ 2580.285800] phy1-sta0: send auth to #b (try 1/3)
Mon Oct 9 22:51:05 2023 kern.info kernel: [ 2582.634912] phy1-sta0: send auth to # (try 2/3)
Mon Oct 9 22:51:08 2023 kern.info kernel: [ 2585.034912] phy1-sta0: send auth to # (try 3/3)
Mon Oct 9 22:51:08 2023 kern.info kernel: [ 2585.303139] phy1-sta0: aborting authentication with # by local choice (Reason: 3=DEAUTH_LEAVING)
You could throw 148 cores at it and have 0.0000% CPU usage and still be hardware limited.
Okay, there are over an hours worth of videos and you did not watch them and tweak in the 15 minutes that passed from my post to your reply..
Not very truthful. Mostly stubborn and beyond helping.