On Saturday, 8 September 2018 19:38:01 CET Sven Eckelmann wrote: [... explanation why this test could create problems for other wifi connections...] > Is there anything which I missed that could ease my mind?
Beside this potential problem, there is also the problem of the interaction
with the ethtool throughput gathering (brought up by Matthias Schiffer [1]
and Matthias Fritzsche [2]). The ethtool code basically prevents the correct
measurement in many situations. I will try to summarize it now:
* ethtool's link_ksettings is not about speed towards a neighbor behind the
interface but about either
- PHY layer speed class from local ethernet port to next peer (for direct
connections)
- connection towards next (internal) switch
- propagated value from a lower layer device (e.g for vxlan)
- "random" value (e.g. tun/tap)
- ...
* often connections indirect (switches, VPN, WiFi bridges, L2 firewalls, ...)
* B.A.T.M.A.N. V requires a measurement for the throughput towards a neighbor
and not the maximum(?) PHY layer speed of the first hop over the current
medium
The proposed solution is to drop the ethtool link_ksettings usage when the
tpmeter (or similar) approach for neighbor speed measurements is integrated.
Kind regards,
Sven
[1] https://github.com/freifunk-gluon/gluon/pull/1872#issuecomment-55767698
[2] https://patchwork.open-mesh.org/patch/17371/#31059
signature.asc
Description: This is a digitally signed message part.
