Testing Wi-Fi latency

Hi,
Last 2 months,I was trying to solve the latency. I have a WDS setup between Xiaomi X3000T (2 weeks ago replaced by Zyxel T-56) and Cudy WR3000 v1 via x86 ( Fujitsu Futro s920). I get 600 up and 400 down ISP speed. I setup SQM on Fujitsu and tested wired trough Xiaomi ( this is the WDS-AP), then I tested wired via Cudy ( WDS- Client / STA) - all fine "A" results for download and upload.
After a while I started testing the latency via WiFi. An the download results were bad ( around 25 ms- 20cm from the AP) and (100ms) 2 meters from the WDS point. However the upload was great 1-2ms.
I started digging, as I was sure that the s920 CPU can handle these type of speed: I followed all guides given by moeller0 and FailSafe, but nothing changed. I could not fight against the download latency, no matter what I do.
As I changed my WDS-AP from Xiaomi to Zyxcel and the same result appeared, out of the blue - I decided to see and adjust the transmit power between the WDS nodes.
Guess what - an increase of 2 dBm in transmit power - made my latency to disappear.
I have kept the transmit Wifi power as low as possible in case of any interference, but it seems not to be a good idea.
I am posting this topic in case anyone experience similar problems.
Kr
K

Slightly off-topic, but a good tool for testing WiFi latency is Crusader. Crusader creates three bursts of traffic: download, upload, and bi-directional, continually measuring latency. It requires two computers: a "client" running on Wi-Fi, the "server" plugged into an Ethernet on your main router's LAN port.

Because both computers (client and server) are on your local network, the test isn't affected by your ISP connection.

Download one of the pre-built GUI binaries for your systems. Each binary can act as either server or client.

You can also look at updated "local test" documentation - the main repo README hasn't yet been updated for the 0.3.2 release.

2 Likes

Yea, seems you lowered your power and others now interfere with you.

1 Like

What I do not understand is: ok the transmit power was the problem, but why the upload test via waveforum was reported fine, but the download one was bad?
PS: most likely I will not understand a technical answer, but in all reality this triggered me dig deeper. In addition - without SQM - I received full speed of download, with SQM @ 550 megabit- I received around 470. This totally confused me and I was digging around SQM instead of transmission rate.
@richb-hanover-priv next week I am expecting to receive the other T-56 which I will setup as a WDS-client/STA 0 I will test that out! Thanks
Kr
K

While this doesn't address your issue, there is also something as 'too close' to the AP - avoid getting closer than at least ~1m to the AP.

You increased the Tx on both devices.

One needed more power and I'm going to guess it was the first AP your testing device 'sees'.
Do you see where this is going?

1 Like

AP was 22 dBm and the sta was 23 dBm. Now it is 24 and 23 - and it is fine. You win:)

Thanks @slh , but believe me - I tested all over the places, and with all I can find in the forum as AQL/SQM topics. And it is not just one node but 2 wired and wireless.
Btw- I am not sure what we are searching for - I gave the resolution. This topic was intended to be just informative.
Kr
K

Taking away the title:) why just the download on the first AP?

Your layout is confusing so I'm going to use A and B.

A gives internet to B. IOW A transmits (Tx) to B. Tx Power on A is fine so download is fine.

However B needs a boost. It transmits to A which goes to internet.
Upload.
Low power, poor performance.

Why is one fine @ 23 while another needs 24? Round off errors in reported power, different antennas, different multi-paths.

1 Like

Got it! Thanks!
I guess we can mention this somewhere. It took me just 2 months to find it out:)
In wiki I see topics referring only to decrease the Tx rate.
But I think in the SQM topic, we need to mention the transmit power thing.

Actually, you can use most any 5-year old computer as the server on Ethernet. I even installed the command-line Crusader on a Raspberry Pi 4 and tested at ~1Gbps...

1 Like

Ok, as a summary for an end user:

  1. If you use WDS- your AP transmit power should be greater than you WDS-Client "tranasmit power"
  2. If you have SQM via Wi-Fi, make sure you tweak the transmit power of your WIFi AP
    Kr
    K
    Thanks everyone, and correct me if I am wrong!

A good friend of mine once said "RF can't read". Just use the most amount of [legal] power to accomplish your goal.

(Or not editing default power - then you may have never discovered this.)

1 Like

Shows what happens if you tackle a problem at the wrong layer... hard to fix physical layer issues on l2/3... sorry for wasting your time...

1 Like

You are back to convoluting the two:

You had a case-specific issue that had, as @moeller0, pointed out, nothing to do with the firmware nor settings other than radioB was not set strong enough for radioA see.

It is more like two kids in the woods with flashlights trying to blink morse code to each other:
If A has to keep telling B to resend the message because some of the blinks were lost then it makes sense for B to use a higher setting on the flashlight.
The only reason not to use full power is a Dark Forest approach of using as little as needed; but then it is just easier for me to spoof the low power AP with more power.

TL;DR
The protocols (WDS and SQM) had nothing to do with upload and download quality.
It was just a dim flashlight.

3 Likes

It's complicated... there is good justification to use low power if one deploys a lot of APs then low power allows much better spatial frequency band re-use. But that is contingent upon having a relatively dense set of APs and that mostly makes sense for environments with lots of stations (think conference, sports event, convention, ...). For the at home situation low power still makes some sense, but only if you maintain sufficient stability/capacity/coverage.

3 Likes

I was just about to fix that...

you are right.

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.