Everything is fine, but the range in 5Ghz is worse, the signal penetrates less obstacles, and what follows, you would need several devices, not one, to provide as such Internet at the distance of 100 meters from the device (not 100 m2). My test environment is 2 floors below, but at home you can think about 5GHz, but not on a free air. With the current settings (without helping with external antennas, without special equipment placement and frying neighbors with radio waves ) I get good transfers even up to 150m from the router, but in the test room it sucks. The other thing is that other people at my place also use only 2.4GHz.
The other thing is that the original firmwares are better - and this is where we should improve, not create prostheses - because it's going to happen that the more modern the equipment, the worse it's going to be to get the same results as on old junk (on ea6350v3 I'm getting worse transfers as on wr1043nd v3 and earlier wr1043v1 (where I was getting the best results, but the equipment got fried)).
5GHz attenuation is not that severe with California's wooden frame houses and drywall, so one good router (like r7800 and proper location) can cover the whole house easily.
And since houses are close together, 2.4GHz interference ought to be quite bad. However, OEM firmware always performs much better with 2.4GHz than OpenWrt in spite of all this 2.4GHz interference.
Worse if the house is a typical bunker with multiple reinforced ceilings and thick masonry walls. California in USA have hot climate (good temperatures, not bad humidity), Poland not (freeze temperatures in 1/2 of year, bad humidity for 3/4 year) ...
Bunker? It seems to have been built to prepare for wars, against that rogue nation in the 21st century.
, no- this is typical house in 1980-1995 years- i.e. 'cubic' (in polish lang: "kostka").
Now are also building houses made of brick and concrete, but lower ones, also in my case, the neighbors will not disturb between each other the ether with too strong 2.4GHz for a long time - and it happens (that even in my case they transmit at full power and at 40MHz)...
Edit: OK, I tested patches of AQL, and... I delete all without 330- seems to be useful.
Patch 332-mac80211-fix-ieee80211_txq_may_transmit-regression causes log errors.
Patch 331-mac80211-improve-AQL-tx-time-estimation causes worse speed in speed tests (especially at further customer distances from the access point).
Patch 333-mac80211-rework-the-airtime-fairness-implementation will worked (mayble), after rework, now it not compiled without patches 331 and 332.
Patch 330-mac80211-fix-overflow-issues-in-airtime-fairness-cod mayble have potencial on smaller ping (first tests near router).
I rebooted router on 2nd partition (with master 5.10.1xx) and is better... (download, often ping also). Mayble problem with wireless (acces times and speed of Internet - iperf shows almost always better transfers) is not from airtime. Mayble it is about an Minstrel algorithm or something else.
Tests:
Today is 20-22Mbps with speedtest.net, 30-34Mbps with iperf on master 5.10.111, pings from 24 to 28ms.
16-19Mbps, pings 28-34 with on 5.15.38 kernel.
Yesterday on 5.15.38 with all master patches- 8-12Mbps, pings about 40ms , without new patches (delete and recompile) this is same
All on 2.4GHz... Big storm and hail and all the other weather plagues. Today I are no longer working on computer. All devices electric I turned off.
I need to rebuild the environment from scratch because I messed something up (not every compiled image install on router, if it works, it doesn't completely - I wanted to switch from kmod-ath10-ct to normal)....
So after a lot of discussions with Toke (who built the airtime fairness scheduling code), I completely dropped my previous round of patches, reverted the code back to the earlier round-robin scheduler and added a number of improvements on top of it.
In my very basic and limited testing with mt76, latency and throughput are looking good so far.
You can find the changes in my staging tree at https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary (single commit, top of the list).
Please give that a try and let me know if it works better for you guys.
I changed my setup to only include 20 linux clients (no mac or ios clients).
Patches
I applied your new patches on top of latest (as of 3 days ago) openwrt 22.03.
Results
They are the same
high memory usage and then crash (Unable to handle kernel NULL pointer dereference) - report below
more than 3 or 4 clients, download: tcp throughput drops to around 100Mbps and udp throughput halves
more than 3 or 4 clients, upload: udp throughput drops to around 50Mpbs
same results when adding (throughput drops) or removing (throughput increases) clients while running the tests
I checked the build_dir to see if patches were applied correctly for mac80211 files and looks like they were applied. But I am going to do a "super clean" build just in case something didn't compile correct.
Did you have a chance to try 21.02.1 image in your setup? That version was the last OpenWrt version using the round-robin scheduler before it was replaced by VTBA scheduler in later versions. Other than the crash, I'm wondering whether you may also encounter the same throughput drop problem in your setup when using 21.02.1.
Can you also clarify your throughput drops when adding more clients? Did you refer to a drop in total aggregated throughput of all additional clients, or the throughput drop of a single client when additional clients are associated to the wifi network (but without sending traffic in a concurrent manner)?
I didn't test 21.02.1 version yet. I will try that later today.
The test I am running is:
connect 1 client to the AP (only associate)
no traffic is passed
run iperf3 from only first client
start associating other clients without sending traffic in a concurrent manner
only one client is sending traffic, all others are idle.
So the throughput drop I am observing is of a single client when additional clients are associated to the wifi network and the throughput recovers (increases) back to normal as I am disassociating the clients.
Also, it's not just associating clients while the test is running, it's also when more than 3 or 4 clients are associate prior to the test and then when the test is run, the throughput starts off at 50% lower.
To help mitigate the high latency and random crash problems, I disabled AQL on my R7800 (running an old ACWIFIdude's 22.03 image 5.10.113 built on May 8 13:53:12 2022). I did notice that single client throughput tended to drop only a bit with other associated clients (about 6) having slight concurrent download speeds (e.g. watching youtube @720p and browsing web). With AQL being enabled, the speed drop (for the same single client) was more obvious in the same condition. It's possible that AQL and ATF (aka VTBA scheduler) are not supposed to be in a marriage Perhaps their coliving for the past year has proved their irremediable incompatibility, and should end in an amicable departure from each other. Felix was their matchmaker and will also be their divorce lawyer
For example (approximately):
450 Mbps -> 390 Mbps (AQL disabled) vs. 260 Mbps (AQL enabled).
Before switching to 21.02.1, can you please do this experiment with your current image:
Is it possible your clients could be running netperf and we get those sort of tests back?
It is the comparison plots that are the most helpful. I note that with most wifi (without these patches), performance drops precipitously in the first place.
If it's possible for use to schedule a live videoconference or a meeting via irc, I am in the PST time zone, and available most mornings except tuesdays, where I am available 8:30-9:30 AM only.
According to the original paper (https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf), it seems that the validation of the ATF scheduler implementation was done with the ath9k driver instead of the ath10k driver. Most of the reported issues so far seem to be related to ath10k. If that's the case, the peculiarities in the behavior of the ath10k driver/firmware may dictate more extensive modifications in the ATF implementation in order to accommodate them.
"We have implemented our proposed queueing scheme in
the Linux kernel, modifying the mac80211 subsystem to
include the queueing structure itself, and modifying the
ath9k and ath10k drivers for Qualcomm Atheros 802.11n
and 802.11ac chipsets to use the new queueing structure.
The airtime fairness scheduler implementation is limited
to the ath9k driver, as the ath10k driver lacks the required
scheduling hooks."
According to Felix' latest patch (after his numerous communications with Toke):
The virtual time scheduler code has a number of issues:
10 - queues slowed down by hardware/firmware powersave handling were not properly handled.
12 - on ath10k in push-pull mode, tx queues that the driver tries to pull from were starved, causing excessive latency
14 - delay between tx enqueue and reported airtime use were causing excessively bursty tx behavior
17 The bursty behavior may also be present on the round-robin scheduler, but there it is much easier to fix without introducing additional regressions
20 Signed-off-by: Felix Fietkau <nbd@nbd.name>
@sjpacket, do the patches make any difference in your test compared to leaving them out without any other changes to the tree? Does it make a difference if you only use the first patch (330-mac80211-switch-airtime-fairness-back-to-deficit-rou.patch)?
I haven't tested with applying one patch at a time. Will try that this week.
What I have noticed is that I do not see a crash when I switched to ath10k mainline. I see a crash a soon as I switch to ath10k-ct.
Results:
openwrt 22.03 + ath10k-ct + no patches = crash (OOM)
openwrt 22.03 + ath10k-ct + latest patches = crash (NULL Pointer deference)
openwrt 22.03 + ath10k + no patches = no crash
openwrt 22.03 + ath10k + latest patches = no crash (I see a quick dip around 8 mins or so but throughput recovers fine)
There are a lot of variables and patches to test and I also need to make sure I don't have any issues in my test setup.
Thanks, @sjpacket. The NULL pointer dereference crash that you pointed out also seems to be caused by OOM. It happens in a completely unrelated place, so I don't think it's directly related to my patch, except for the fact that my patch might slightly change memory usage patterns.
How is latency/throughput with my patch on mainline ath10k?
Hi @vochong,
regarding ATF and AQL: AQL is essential for making ATF work well. If AQL significantly reduces throughput, then that's an important issue which needs to be fixed. Please let me know how well the current version with my patches works for you with AQL and ATF enabled.