On Friday, 5 April 2024 10:06:56 CEST berkay.demirci@protonmail.com wrote:
We also did tests in virtual environment and according to this commit https://git.open-mesh.org/batman-adv.git/commit/6e860b3d5e4147bafcda32bf9b3 e769926f232c5, ethtool link speed detection used to be disabled for such cases but got reverted since automatic measurements aren't implemented.
No. Batman-adv used the ethtool 'auto-negotiation' on/off state to decide whether the the ethtool throughput value should be trusted.
As the commit states, the 'auto-negotiation' state has no impact on whether the reported throughput value should be trusted. Auto-negotiation could be on or off and still the value is wrong.
dynamically calculating throughput is a must because like I said, one of our modems have a shorter distance range so it is faster when two nodes are close but as nodes move away, there is lots of packet loss so the real throughput drops as well, but with overriden throughput value stays the same.
You keep keep mentioning "modems have distance", "move away", "ethtool", etc without having explained what your setup is. Without providing details about these "modems with range" and what interface types you are talking about, nobody can really comment on your setup.
I see that the last patch for tp fallback was written in 2018, has there been no more progress since then? And what are the problems with it?
The main obstacle is time & energy to work on the tp fallback integration. Open issues were mentioned in the responses to the various patches.
f you are interested n spending time on these patches, I am happy to provide assistance.
Cheers, Marek