Ath9k distance

Of course it will effect throughout.

It is a parameter used by wifi driver, best to keep it at default unless you are using long-range antenna to connect devices.

I read the details a while ago, it has something to-do with allowing a longer time for collision detection before transmitting due to the long path the signal travels.

So basically more time waiting before transmitting causes throughput to drop

2 Likes

Light travel by about 300000km/s, 50km range won’t really do much for the practical time for signal travel.
The transatlantic opto fibers really doesn’t lower speed just because they are 20000km long.

1 Like

Throughput must be affected. RF travels at the speed of light.

:bulb: You set the radio to pause in order to wait for a client at a distance 50 kilometres.

Please understand what this means before you ask about the throughput - as it's not directly related to the setting. You make the channel less available, hence less throughput.

You should only set the Distance Optimization to the true most physically distant client.

Multiply by 2. A packet and its reply is a 100 km round trip (not counting processing by the WiFi and CPU on both sides).

1 Like

Is there a way to set a relatively large distance at a relatively close distance to obtain a higher throughput ?

Distance is not only set to 50km to affect throughput, 10km to 20km will affect throughput, but the impact is smaller.

You really need to be more precise with your language. This makes no sense whatsoever because we cannot understand which "distance" refers to physical distance vs the one that refers to the distance parameter.

That said, it doesn't appear that you are paying attention to anything anyone has said here.

  • You will have a hard time getting signals across what appears to be a very significant distance (1-50 kilometers physical distance??)
  • You cannot simulate the distance by simply changing the wifi distance parameter.
    • you need to either have specialized RF equipment to simulate the physical distance, or you need to set these up at the real distances of interest.
  • As physical distance increases, bandwidth decreases as a function of signal strength / SNR and also propagation delays.
  • As the distance parameter increases, bandwidth decreases as a function of the driver optimizing for various factors to improve the reliability of the link.
  • The distance parameter is presumably included to allow optimization (for robustness) when the radios are deployed at the desired distance. This very likely needs to be done with actual in-situ experimentation.
  • Distance will have an impact on bandwidth. Period.
  • You can remove the distance parameter so that the driver uses the default values, and you will have improved performance for most situations.
3 Likes

The speed of light is about 300 meters per microsecond.

As I understand it, the only effect of the distance setting is to increase some microsecond level timeouts to allow time for the radio waves to travel. In particular the station receiving a data packet from an AP is expected to send an ACK packet almost instantly afterward, and by default the AP will not wait very long for it.

The default settings are optimal for short distances the way WiFi is typically used.

3 Likes

You may not understand what I mean

  1. Setting 50km will reduce throughput (option diistance '50000'), 2 device in my desk.
    2.I put the setting to 50km, the throughput will be even lower.
  2. I want to make Distance without affecting the throughput.
  3. Finally I placed it to 50km and re-cesti throughput

You have said these things several times. We have explained why these work the way they do and told you that you cannot have what you want.

1 Like

As a vastly oversimple analogy, imagine there's a musical band playing, and you walk away from them. Eventually you'll be so far away you can't hear all the instruments, you only hear the drums. It doesn't matter if the other musicians are playing or not, you can't hear them.

Now you're in the same room with the band, but you've told them to play as if the audience is distant. This means that all the players except the drummer stand down and don't play at all.

1 Like

To the original poster, I think I get what you're trying to do. To preserve throughput at physical distance, someone has thought of the same scenarios as you so they went about it this way: by manipulating ACK. This was part of ath9k "dynack" feature. You can run it through using sogou translate here:

https://lists.openwrt.org/pipermail/openwrt-devel/2018-July/018771.html

Of course, that is only one gentleman's attempted solution -- the possibility that other solutions exist is probably high and waiting to be discovered.

Thanks!

I tested this a long time ago. It automatically calculates ackto, which is actually the same as setting distance.

Every time you increase the distance parameter throughput will decrease because the wifi will add a bigger delay between packet transmissions to allow for the longer path.

Don't ask me the technical details why. I read about over 2 years ago and am a bit vague.

1 Like

It's simple. You have to wait for the 50 km device to send a [return] signal at the speed of light, therefore the radio has to account for this in some way. If it didn't, the AP would never "hear" the device 50 km away...why?

Because if it's set under the true distance, the AP wouldn't have waited long enough for the wireless frame to arrive there (so simple).

:man_facepalming:

Yes, this is what we're trying to explain. You're literally asking the radio to pause for a device (up to) 50 km away; then you're wondering why the traffic is slower. :confused:

2 Likes

And the real world for fix throughput on a radio link is to send on many parallel channels at the same time.

But 802.11 is not a radio link standard!

  • This won't work for a single TCP or UDP stream, you only use the one radio (more specifically, a single radio PHY)
  • If you mean MIMO, etc., sure - in fact I assumed this was operational currently (the issue is the pause for 50 km setting)
  • I think you're still forgetting, the second channel still must be configured to hold/wait/pause for a 50 km client too :wink:

I'm always lost in the threads...as to why concepts of: latency, delay, logical round-trip-times, physical travel time, etc. are forgotten when WiFi/RF is discussed. :thinking:

???

I'm guessing this was a joke...but I didn't understand it...because that's exactly what 802.11 is.

You cant have a WiFi LAN with radius 50km how big and positive thoughts you may have.

???

Actually, you can have one much longer (the known current record is 382 km):

(Where are you getting your facts regarding WiFi?)

See:

1 Like

ackto is calculated by sending and receiving timestamps

ackto = ack_ts - st_ts->tstamp - st_ts->dur;

Two devices are on my desk, the same location, 20M bandwidth and 10M bandwidth, the difference between the time stamps sent and received is very different

ls :
20M:
ack_ts = 9574642, tstamp = 9574536, dur = 52
9574642-9574642= 106

10M:
ack_ts = 218056504, tstamp = 218056258, dur = 56
218056504-218056258=246

Does this look normal?