First of all, thanks for your help!
Yeoh, the patch for ath9k_htc was already applied.
I have added some Debug messages in mac80211 and logged the output of mpath
dump for the specific path.
More exactly I logged the metrics in function "hwmp_route_info_get" because of
this statement:
if (SN_GT(mpath->sn, orig_sn) ||
(mpath->sn == orig_sn &&
new_metric >= mpath->metric))
{
In my log I can see that sometimes the orig_sn is greater than mpath->sn and
the path is taken over while the metric is bad.
Details to the mesh network:
Node A -> Node B
bc:30:7d:97:9e:24 -60 dBm bc:30:7d:97:9c:33
To simulate traffic between these nodes I use iperf.
Log of mpath dump on Node A, when the path changes:
08-55-11
bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 927 127 0 1676
100 0 0x5
08-55-12
bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 928 114 0 4403
100 0 0x15
08-55-13
bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 928 114 0 3136
100 0 0x15
08-55-14
bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 928 114 0 1934
100 0 0x15
08-55-16
bc:30:7d:97:9c:33 bc:30:7d:97:9e:22 wlan0 929 241 0 4747
100 0 0x5
08-55-17
bc:30:7d:97:9c:33 bc:30:7d:97:9e:22 wlan0 929 241 0 3455
100 0 0x5
08-55-18
bc:30:7d:97:9c:33 bc:30:7d:97:9e:22 wlan0 929 241 0 2265
100 0 0x5
08-55-19
bc:30:7d:97:9c:33 bc:30:7d:97:9e:22 wlan0 929 241 0 1070
100 0 0x5
08-55-21
bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 930 114 0 3834
100 0 0x15
08-55-22
bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 930 114 0 2580
100 0 0x15
08-55-23
bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 930 114 0 1391
100 0 0x15
08-55-24
bc:30:7d:97:9c:33 bc:30:7d:97:9c:33 wlan0 931 114 0 4117
100 0 0x5
Output of the metrics (from new to old):
Jun 11 08:55:19 debug kern kernel: [166562.390000] wlan0: LG: new
metric1 for bc:30:7d:97:9c:33: 114
Jun 11 08:55:19 debug kern kernel: [166562.390000] wlan0: LG:
mesh_path_assign_nexthop bc:30:7d:97:9c:33 nexthop: bc:30:7d:97:9c:33
Jun 11 08:55:19 debug kern kernel: [166562.390000] wlan0: LG:
metrics #1 of bc:30:7d:97:9c:33: mpath->sn 929 | orig_sn 930 | orig_metric 0 |
last_hop_metric 114 | new_metric 114 | old_mpath->metric 241
Jun 11 08:55:15 debug kern kernel: [166558.393000] wlan0: received
PREP from bc:30:7d:97:9c:33 | metric: 241
Jun 11 08:55:15 debug kern kernel: [166558.393000] wlan0: LG: new
metric1 for bc:30:7d:97:9c:33: 241
Jun 11 08:55:15 debug kern kernel: [166558.393000] wlan0: LG:
mesh_path_assign_nexthop bc:30:7d:97:9c:33 nexthop: bc:30:7d:97:9e:22
Jun 11 08:55:15 debug kern kernel: [166558.393000] wlan0: LG:
metrics #1 of bc:30:7d:97:9c:33: mpath->sn 929 | orig_sn 929 | orig_metric 127
| last_hop_metric 114 | new_metric 241 | old_mpath->metric 600
Jun 11 08:55:15 debug kern kernel: [166558.382000] wlan0: received
PREP from bc:30:7d:97:9c:33 | metric: 600
Jun 11 08:55:15 debug kern kernel: [166558.382000] wlan0: LG: new
metric1 for bc:30:7d:97:9c:33: 600
Jun 11 08:55:15 debug kern kernel: [166558.382000] wlan0: LG:
mesh_path_assign_nexthop bc:30:7d:97:9c:33 nexthop: bc:30:7d:97:91:12
Jun 11 08:55:15 debug kern kernel: [166558.382000] wlan0: LG:
metrics #1 of bc:30:7d:97:9c:33: mpath->sn 928 | orig_sn 929 | orig_metric 316
| last_hop_metric 284 | new_metric 600 | old_mpath->metric 114
Jun 11 08:55:11 debug kern kernel: [166554.372000] wlan0: LG:
fresh_info = false | mpath->sn 928 | orig_sn 928 | new_metric 983 |
old_mpath->metric 114
Jun 11 08:55:11 debug kern kernel: [166554.372000] wlan0: LG:
metrics #1 of bc:30:7d:97:9c:33: mpath->sn 928 | orig_sn 928 | orig_metric 459
| last_hop_metric 524 | new_metric 983 | old_mpath->metric 114
So can this be the problem why the path changes while there is a single hop
with a better metric??
Thanks,
Lukas
> Lukas is using the ath9k_htc, so it is using HW rate control. Minstrel
> probably won't help much in his case.
>
> Lukas, please make sure that the following patch is available or applied
> (http://www.spinics.net/lists/linux-wireless/msg120948.html)
> for all the nodes.
>
> By the way, we may rethink the metric calculation cause we may not have the
> info on TxRate for some drivers, such as ath10k.
>
> -----
> Chun-Yeow
>
>
>
> On Thu, Jun 11, 2015 at 3:20 AM, Bob Copeland via Devel
> <[email protected]> wrote:
> > On Wed, Jun 10, 2015 at 06:29:01PM +0200, Jean-Pierre Tosoni via Devel
> > wrote:
> >> Hi everybody,
> >>
> >> About the metric computation from the tx_rate:
> >> We made a patch (against compat-wireless 2014-06-03) that uses an API
> >> added some time ago by Antonio Quartulli The patch finds the expected
> >> throughput from minstrel_ht when possible
> >>
> >> Don’t know if it will solve you issue, but anyway here it is:
> >
> > Great! I've been meaning to do this as well.
> >
> > Can you share any before/after results?
> >
> > --
> > Bob Copeland %% http://bobcopeland.com/
> > _______________________________________________
> > Devel mailing list
> > [email protected]
> > http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> [email protected]
> http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
