On Freitag, 7. September 2018 11:59:51 CEST Marek Lindner wrote:
Under normal circumstances B.A.T.M.A.N. V retrieves the neighbor throughput values to populate its metric tables from the various drivers such as WiFi throughput tables and Ethernet throughput.. Whenever the interface drivers do not export link throughput information manual overrides become necessary. To further automate and thus better support these setups, ELP may call the batman-adv throughput meter to schedule a throughput estimation to be used to populate the metric table.
I know that this patchset is required to have some throughput estimates for non-wifi connections (or for wifi drivers without expected throughput). But since we have the other discussion with Ligang LIU, I still have to bring this up:
We already know that something (maybe ELP unicast probes and the related messages) are "breaking" the connectivity between 2 neighbors in Ligang LIU's test setup (with 6 not so well connected nodes). It also seems to be the case that the driver doesn't return the expected throughput for each neighbor all the time and this missing data would then trigger the single-link tpmeter test.
The test seem to be done every 60 seconds (or longer when there is another source for the throughput) for each neighbor and by default 1s long. My assumption would be now that this test could be even more harmful for wifi connections than unicast ELP probes (or whatever is causing Ligang LUI's problems). Let us just assume that we have these 6 nodes with 5 neighbors (I see a lot more in real world setups). If the tests on the different nodes don't overlap (which would also be bad for the test results) than all tests would take at least 30 seconds of the 60 seconds. So even without the problem in the "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms" mailing list thread, the tpmeter fallback has a significant cost.
Is there anything which I missed that could ease my mind?
Kind regards, Sven