On 5/22/23 09:56, Ilario via LibreMesh wrote:
> On 5/20/23 18:48, cri via LibreMesh wrote:
>> On 20/05/23 12:28, Pedro via LibreMesh wrote:
>>> As Marek explained to me, this parameter is really related to the
>>> wait time that the radio takes for ack packages
>>>
>>> > For short links that decreases performance because the radio will
>>> needlessly wait longer for ACK packets.
>>>
>>> https://forum.openwrt.org/t/different-distance-optimizations-for-different-frequencies/131217/10
>
> Can anyone test this on a real link?
> For example, testing the performances on a 1 km link, comparing the
> "distance" setting at "1 km" and "10 km".
> I don't have any link to test this on.
>
Hi!
Here is a test with a link that is 2100m away.
https://pic.infini.fr/gallery#FAQVRcK7/FAAHEvTC.png,Z3B2pJPZ/erXwdflW.png,3pllMRUL/DANp7otP.png,6n9T3km9/PJTQvjuL.png
The first keeping 2100m as distance, the second with 5000m and the third
10000m.
However subsequent tests gave very different results, and the link
normally has an oscillation of around 10dbm [51-64] (but this seems
common to many other devices).
But it doesn't seems clear to me how long to wait for the device to
actually apply the distance, or whether routing protocols may also
affect this time. Also I changed the distance of these devices just 2-3
days ago (after reading this thread in mailing list) from 9000m to 2100m
but also with a continuous monitoring of the throughput, via prometheus
looking at wifi_station_expected_throughput_kilobits_per_second, it
doesn't seems to change much, at least in terms of throughput.
(*There would be a link at around 1km but the oscillations and signals
of this are even worse)
>> this confirm that not exist a solution working well for all devices,
>> so o we provide different network-profiles/libremesh/default
>> for subtargets and build them for each
>> o we set really high and advise too the users how change it
>>
>> la mia opinione, e voi?
>> my opinion and yours?
>
> What I would do is provide a working default configuration, even if it
> has poor performances, and advise users on how to improve them.
>
> I think this is the standard thing in LibreMesh, that we do also for
> other cases, for example we configure AP, APname and mesh on each radio,
> even if maybe is not used; we configure the routing protocols also on
> the WAN, even if is quite never used; we configure both br-lan bridge
> and routing protocols on each ethernet port, even if this is a bad
> configuration for both of the possible uses of the port, but we do that
> so that things always work, even if not in an optimal way.
>
> In my opinion, this is a thing important enough to include also in the
> 2020.X upcoming release based on OpenWrt 19.07 (the release 2020.3 is
> ready but has not been released yet, so that we can add this small
> modification and release it as 2020.4).
>
> Additionally, another thing we coooooooooould do (maybe it is late for
> including it in a 2020.X release) is to adopt the "auto" distance
> available in ath9k wireless driver and implement it in LibreMesh:
> https://github.com/libremesh/lime-packages/issues/932
>
> Ciao!
> Ilario
>
--
gothos
PGP Key ID: 0x6406B32F2CEC0008
PGP Key server:
https://keys.openpgp.org/
&References=ac657436-2040-d60a-9dfc-adffbf993d01@esiliati.org&In-Reply-To=ac657436-2040-d60a-9dfc-adffbf993d01@esiliati.org&Body=On%202023-05-23%2014:28,%20gothos%20wrote:%0A>%20On%205/22/23%2009:56,%20Ilario%20via%20LibreMesh%20wrote:%0A>%20>%20On%205/20/23%2018:48,%20cri%20via%20LibreMesh%20wrote:%0A>%20>>%20On%2020/05/23%2012:28,%20Pedro%20via%20LibreMesh%20wrote:%0A>%20>>>%20As%20Marek%20explained%20to%20me,%20this%20parameter%20is%20really%20related%20to%20the%20%0A>%20>>>%20wait%20time%20that%20the%20radio%20takes%20for%20ack%20packages%0A>%20>>>%0A>%20>>>%20%C2%A0>%20For%20short%20links%20that%20decreases%20performance%20because%20the%20radio%20will%20%0A>%20>>>%20needlessly%20wait%20longer%20for%20ACK%20packets.%0A>%20>>>%0A>%20>>>%20https://forum.openwrt.org/t/different-distance-optimizations-for-different-frequencies/131217/10%0A>%20>%20%0A>%20>%20Can%20anyone%20test%20this%20on%20a%20real%20link?%0A>%20>%20For%20example,%20testing%20the%20performances%20on%20a%201%20km%20link,%20comparing%20the%20%0A>%20>%20%22distance%22%20setting%20at%20%221%20km%22%20and%20%2210%20km%22.%0A>%20>%20I%20don't%20have%20any%20link%20to%20test%20this%20on.%0A>%20>%20%0A>%20%0A>%20Hi!%0A>%20%0A>%20Here%20is%20a%20test%20with%20a%20link%20that%20is%202100m%20away.%0A>%20https://pic.infini.fr/gallery#FAQVRcK7/FAAHEvTC.png,Z3B2pJPZ/erXwdflW.png,3pllMRUL/DANp7otP.png,6n9T3km9/PJTQvjuL.png%0A>%20%0A>%20The%20first%20keeping%202100m%20as%20distance,%20the%20second%20with%205000m%20and%20the%20third%20%0A>%2010000m.%0A>%20However%20subsequent%20tests%20gave%20very%20different%20results,%20and%20the%20link%20%0A>%20normally%20has%20an%20oscillation%20of%20around%2010dbm%20%5B51-64%5D%20(but%20this%20seems%20%0A>%20common%20to%20many%20other%20devices).%0A>%20But%20it%20doesn't%20seems%20clear%20to%20me%20how%20long%20to%20wait%20for%20the%20device%20to%20%0A>%20actually%20apply%20the%20distance,%20or%20whether%20routing%20protocols%20may%20also%20%0A>%20affect%20this%20time.%20Also%20I%20changed%20the%20distance%20of%20these%20devices%20just%202-3%20%0A>%20days%20ago%20(after%20reading%20this%20thread%20in%20mailing%20list)%20from%209000m%20to%202100m%20%0A>%20but%20also%20with%20a%20continuous%20monitoring%20of%20the%20throughput,%20via%20prometheus%20%0A>%20looking%20at%20wifi_station_expected_throughput_kilobits_per_second,%20it%20%0A>%20doesn't%20seems%20to%20change%20much,%20at%20least%20in%20terms%20of%20throughput.%0A>%20%0A>%20(*There%20would%20be%20a%20link%20at%20around%201km%20but%20the%20oscillations%20and%20signals%20%0A>%20of%20this%20are%20even%20worse)%0A>%20%0A>%20>>%20this%20confirm%20that%20not%20exist%20a%20solution%20working%20well%20for%20all%20devices,%0A>%20>>%20so%20o%20we%20provide%20different%20network-profiles/libremesh/default%0A>%20>>%20for%20subtargets%20and%20build%20them%20for%20each%0A>%20>>%20o%20we%20set%20really%20high%20and%20advise%20too%20the%20users%20how%20change%20it%0A>%20>>%0A>%20>>%20la%20mia%20opinione,%20e%20voi?%0A>%20>>%20my%20opinion%20and%20yours?%0A>%20>%20%0A>%20>%20What%20I%20would%20do%20is%20provide%20a%20working%20default%20configuration,%20even%20if%20it%20%0A>%20>%20has%20poor%20performances,%20and%20advise%20users%20on%20how%20to%20improve%20them.%0A>%20>%20%0A>%20>%20I%20think%20this%20is%20the%20standard%20thing%20in%20LibreMesh,%20that%20we%20do%20also%20for%20%0A>%20>%20other%20cases,%20for%20example%20we%20configure%20AP,%20APname%20and%20mesh%20on%20each%20radio,%20%0A>%20>%20even%20if%20maybe%20is%20not%20used;%20we%20configure%20the%20routing%20protocols%20also%20on%20%0A>%20>%20the%20WAN,%20even%20if%20is%20quite%20never%20used;%20we%20configure%20both%20br-lan%20bridge%20%0A>%20>%20and%20routing%20protocols%20on%20each%20ethernet%20port,%20even%20if%20this%20is%20a%20bad%20%0A>%20>%20configuration%20for%20both%20of%20the%20possible%20uses%20of%20the%20port,%20but%20we%20do%20that%20%0A>%20>%20so%20that%20things%20always%20work,%20even%20if%20not%20in%20an%20optimal%20way.%0A>%20>%20%0A>%20>%20In%20my%20opinion,%20this%20is%20a%20thing%20important%20enough%20to%20include%20also%20in%20the%20%0A>%20>%202020.X%20upcoming%20release%20based%20on%20OpenWrt%2019.07%20(the%20release%202020.3%20is%20%0A>%20>%20ready%20but%20has%20not%20been%20released%20yet,%20so%20that%20we%20can%20add%20this%20small%20%0A>%20>%20modification%20and%20release%20it%20as%202020.4).%0A>%20>%20%0A>%20>%20Additionally,%20another%20thing%20we%20coooooooooould%20do%20(maybe%20it%20is%20late%20for%20%0A>%20>%20including%20it%20in%20a%202020.X%20release)%20is%20to%20adopt%20the%20%22auto%22%20distance%20%0A>%20>%20available%20in%20ath9k%20wireless%20driver%20and%20implement%20it%20in%20LibreMesh:%0A>%20>%20https://github.com/libremesh/lime-packages/issues/932%0A>%20>%20%0A>%20>%20Ciao!%0A>%20>%20Ilario%0A>%20>%20%0A>%20%0A>%20--%20%0A>%20gothos%0A>%20PGP%20Key%20ID:%200x6406B32F2CEC0008%0A>%20PGP%20Key%20server:%20https://keys.openpgp.org/%0A>%20%0A>%20 "Reply to this message")
