I have a problem choosing the right 5Ghz channel.
right now I use 36 but when I scan channel 36 is really crowded.
I have 3 AP's using roaming.
when I select channel 153, wifi get's instable and unworkable
when I select 40, still the ap's insist on using 36,
when I select 48(which is free). 2ap's are using 48 and one insists on using 44, also the connection isn't what it should be.
So my conclustion would be that 36 is the best channel, even 20 of my neighbors use the same channel.
could that be correct, or are there better ways to select a channel?
for 2.4 Ghz I just scan and use the channel which is the least listed and that always works.
That explains some stuff, it says
" Use wide channels until you can’t" and if I use 80Mhz, which still is possible, basically I always have channel 42 if I stay in UNII 1
I do not have any performance issues or stability issues(Related to the channel), only I was wondering if it could be better, Most of the time my download is around 300Mbps.
in this case the author of the page I think he made a mistake stating:
"Use wide channels until you can’t".
I assume he meant if the channel is not crowded and there are no disturbances also use the maximum amplitude (80MHz or 160MHz)
but in your case that there are disturbances and crowding, I would choose either another channel (best solution) or a reduction in bandwidth (average solution).
300 Mbit/s from a wifi point of view is excellent, if I were you I wouldn't touch anything
for example in my case:
channel 36 (80MHz power 23 dBm) is excellent because it has a higher power
channel 149 (80MHz power 13 dBm) is still good but has a lower power than 36
and here is the explanation of those anomalies you found on channel 153 which if you have a band of 80MHz goes right from 149+153+157+159+161
2.4GHz is very good for long distances but not for speed (in this case it really depends on your file transfer needs).
in my case I left it deactivated I prefer the 5GHz distributed among multiple nodes with different channels (36 the first and 149 the second), but I don't have many neighbors with 5GHz routers or I never noticed because I don't receive them.
I wouldn't call 300Mbit on 80Mhz excellent (unless its a single-stream client), I can get ~800Mbit on a NanoHD WiFi 5 2x2 MIMO, ~900Mbit on WiFi 6. Granted, only in the same room as the AP.
It generally seems to come down to the specific devices. I did used to get much slower speeds and is one reason I unfortunately no longer run OpenWRT as the WiFi 6 AP I needed to get better speeds does not support it.
Unfortunately there will always be huge inconsistencies with how one device and another works with OpenWRT, as its a limitation in either the hardware or drivers. As were working with open source drivers, they often lack the optimisations of stock firmware too.
it depends on the client if mimo 1x1 is in line with the performance
it would be more correct to say that hardware manufacturers should release their drivers under gpl (then also Openwrt) it would have better performance
Good luck with that, its even worse on smartphones where all the main things like the camera, radios, etc are locked to the specific kernel build. Very annoying.
I think I won't touch it, all changes I make do seem to make thing worse.
I don't know what a single stream client it, I use Oakla on my client devics to test, even when other devices are streaming video over wifi.
I think that would improve stuff a lot, however manufactures probably are not willing to do so it they haven't already, it's just for my next device I will need to check this before. Now we just have to deal with this I think.
regarding manufacturers and their choice to distribute drivers and documentation under Gpl (obviously it's their choice)
we are poor users who have to choose whether to stay on the firmware proposed by the manufacturer (which usually has better performance) or to migrate for example to Openwrt (which is easier to configure, with the right knowledge) which has many packages and many utilities that routers owners have not and last but not least a timely code check and correction of the latter.