net/netstats: L1/L2 per neighbor statistics

[benpicco]

Contribution description

This is a rebase of a previous PR to add a database for neighborhood metrics.
Those are needed for generating better routes with RPL (MR-HOF #7450).

I think it makes sense to attach this directly to the netifnetdev as originally proposed as those statistics are per-interface anyway.

Only rebase & slight cleanup done so far.

Testing procedure

When running examples/gnrc_networking you should now have a neigh command that prints statistics about neighbors.

Issues/PRs references

taken over from #6873
needed for #14623

[chrysn]

I've given this a first practical test by adding all the netstats_neighbor_* from the other example to an gnrc_border_router, where the BR is a nrf52840dongle that talks to a particle-xenon and another nrf52840dongle; both leaf nodes were continuously being pinged from upstream, and I varied the transmission properties by moving water containers into the leaf node's near field (ie touched the board).

In the quick test, the LQI and RSSI values were plausible ("-73 dBm 90" -- not great, not terrible). Other data stayed empty (while the received counter went up, sent and average tx time was 0 throughout) until I enabled more netstats (l2, ipv6, rpl) that were already active in the GNRC example -- are they actual dependencies?

ETX stayed at 200% for all links; I presume that'd need additional work for the nrf802154 driver?

When I powered off one of the leaves, its stats stayed constant (with the fresh=16) for minutes, even after I tried pinging them from the netstats board. That's consistent with the 10 minutes default before halving. Is that a good strategy? Allowing radio contact every five minutes for just a few packages to come through suffices to get what appears on the neigh interface to be a perfectly viable link, even though it only works while some door is open.

On the BR node, I'm seeing stats not only for the 6lo interfaces but for all. It's probably not urgent in this initial iteration, but is there a roadmap to not storing practically irrelevant stats there? (CDC-ECM is quite stable ;-) )

[bergzand]

ETX stayed at 200% for all links; I presume that'd need additional work for the nrf802154 driver?

ETX relies on NETOPT_TX_RETRIES_NEEDED. @benpicco I don't want to shove more work on your plate, however do you think you could add an ETX_INVALID value for when the driver doesn't implement the netopt mentioned here? I don't mind if you postpone this to a follow up (not necessarily by you).

[benpicco]

ETX stayed at 200% for all links; I presume that'd need additional work for the nrf802154 driver?

Can you try with USEMODULE += netdev_ieee802154_submac and #15208

On the BR node, I'm seeing stats not only for the 6lo interfaces but for all. It's probably not urgent in this initial iteration, but is there a roadmap to not storing practically irrelevant stats there? (CDC-ECM is quite stable ;-) )

Good point!

When I powered off one of the leaves, its stats stayed constant (with the fresh=16) for minutes, even after I tried pinging them from the netstats board. That's consistent with the 10 minutes default before halving. Is that a good strategy? Allowing radio contact every five minutes for just a few packages to come through suffices to get what appears on the neigh interface to be a perfectly viable link, even though it only works while some door is open.

Hmm I must admit that I didn't look much into how the 'freshness' is supposed to be used.
Maybe @bergzand still remembers? 😉

however do you think you could add an ETX_INVALID value for when the driver doesn't implement the netopt mentioned here?

How about just leaving it at 0 and then handling it like LQI and RSSI (if it's 0 set the value directly, otherwise use EWMA).

Then we can always handle 0 as invalid.

In an ideal world, all drivers would already be ported to the sub-mac and then we would fall back to software retransmissions if ETX stats are requested and the hardware does not support reporting them.

[chrysn]

USEMODULE += netdev_ieee802154_submac and #15208

That makes it go down from 200% to 100% initially (as confidence is gained that the device is there), but levels at 100% even when I observe a loss of around 3% (which in first approximation means 105% ETX) or unplug the device for a minute. Funnily, it even keeps going down to 100% if, after a reboot, it is unplugged when the ETX is around 105%.

[benpicco]

Ah retrans always gets re-set after send - try 4871b00.
Although I should probably just use the new ieee802154_tx_info_t.

edit nvm, still reports 0

[benpicco]

ACKs are not enabled by default with the sub-MAC.
With

ifconfig 6 ack_req

I get the expected results.

[miri64]

Some last style and code improvement nits remain. Other then that, this ready to merge, so please squash immediately.

[miri64]

I like when people know how to use Git features 🙂

[benpicco]

Rebased again to the merge of #15694
Resolved the conflict gnrc_netif _send().

Soft-ACK from my side. @maribu could you give this one final look regarding the usage of tx_sync in gnrc_netif's _send? Just to be on the save side.

[maribu]

looks good to me

[miri64]

Please squash

[miri64]

ACK!