Wondering if this is an artifact of the QCA chip firmware in the PAL regarding RTS/CTS behavior on the uplink when in client STA mode?Pal telemetry showed the correct 866 Mbps link rate for both transmit and receive when using 80 MHz bandwidth. But for 160 MHz bandwidth, only the receive rate achieved the desired 1733 Mbps; transmit rate remained at 866 Mbps.
The neighboring network isn't simulated. It's a real router and STA.Nice article...
In test cases (2) and (3), simulating the adjacent network, how much additional attenuation are you adding for the simulated neighbor AP?
Could be possible. I checked with octoScope before posting the review. Have not heard anything back.Wondering if this is an artifact of the QCA chip firmware in the PAL regarding RTS/CTS behavior on the uplink when in client STA mode?
So were the stable transfers done with R7800 .58 firmware or earlier? I used version 188.8.131.52 (latest).Interesting that some of those runs were so erratic.
At least with large file transfers I was getting consistent/stable transfers of 104-114 MB/s downlink depending on the location in my home on my R7800 with HT160 (9260ac in a Dell 7577) using a ReadyNAS 524X as the source for downloads.
As for the Intel driver, I think before the .50 or .60 series drivers can’t recall which but there would be occasional dropouts on 160Mhz. Then everything was fine till the latest R7800 .58 firmware that pretty much made 5Ghz useless.
You know - MESH likely is going to land on the same channel across the AP's...The neighboring network isn't simulated. It's a real router and STA.
The two APs are fairly close, in adjacent octoBox chambers, but with doors open.
BTW - nice on the retest - kind of thought something was up with the Octoscope STA's, just didn't make sense there.Could be possible. I checked with octoScope before posting the review. Have not heard anything back.
I've seen this uplink/downlink difference with 80 MHz bandwidth devices too. Usually four stream products.