Skip to content

WIP: gnrc/rpl mrhof#7450

Closed
bergzand wants to merge 12 commits intoRIOT-OS:masterfrom
bergzand:net/rpl-mrhof
Closed

WIP: gnrc/rpl mrhof#7450
bergzand wants to merge 12 commits intoRIOT-OS:masterfrom
bergzand:net/rpl-mrhof

Conversation

@bergzand
Copy link
Copy Markdown
Member

@bergzand bergzand commented Aug 6, 2017

This WIP is an initial work on mrhof (rfc 6719) for RPL.

Depends on #6873 (& co) for ETX statistics.

todo:

  • Decent link local ipv6-address to L2-address conversion
  • Parent selection (sec. 3.2)
  • Preferred parent selection (sec 3.2.2)
  • Correct rank computation (sec. 3.2).
    - [ ] metric containers
  • MAX_LINK_METRIC
  • MAX_PATH_COST

@bergzand
Copy link
Copy Markdown
Member Author

Now depends on #7468 for parent set calculation.

@bergzand bergzand force-pushed the net/rpl-mrhof branch 2 times, most recently from a1f4890 to a4777df Compare August 10, 2017 15:49
@bergzand
Copy link
Copy Markdown
Member Author

Should be feature complete now, so testers are welcome. I'm not going to implement metric containers in this PR and only support ETX as a metric.

PR dependency graph might have gotten a bit messed up, but at least #6873 for the neighbor statistics and #7449 for a bit of additional ETX output should be enough.

@bergzand
Copy link
Copy Markdown
Member Author

As a remark when people are going to test this. This PR relies heavily on ETX functionality of the netstats neighbor module. For this to work correctly, support from the radio is really a must. Only succes/noack reporting is not sufficient to really estimate the link quality. As far as I know only the mrf24j40 and the at86r233 support reading of transmission retries needed for accurate ETX estimation. For the mrf24j40 I have a patch ready contained in the chain of commits in this PR. I don't have access to an at86rf233, so I can't test any patch for transmission retries for that device.

So for testing, I would either advise using mrf24j40's or write a patch for the at86rf233 and use that one.
There are probably more radios that support retransmission statistics, so if #7448 is pulled, similar PR's are welcome :)

@bergzand
Copy link
Copy Markdown
Member Author

As of now, this PR would cause gnrc_rpl to depend on the netstats_neighbor module from #6873. Would it be better to make a gnrc_rpl_mrhof submodule such that the mrhof code (and dependencies) becomes optional? I can imagine lightweight nodes not wanting the extra memory required by the netstats_neighbor module.

@bergzand
Copy link
Copy Markdown
Member Author

Rebased and adjusted for current master

@miri64 miri64 requested a review from cgundogan September 19, 2017 12:11
@miri64 miri64 added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation GNRC Area: network Area: Networking labels Sep 19, 2017
@bergzand
Copy link
Copy Markdown
Member Author

Rebased and uncrustified

Copy link
Copy Markdown
Member

@cgundogan cgundogan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks fine so far, will continue reviewing and testing.

/**
* @brief Store this neighbor as next in the transmission queue.
*
* Set len to zero if a nop record is needed, for example if the
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

len => @p len

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack, will fix

* @brief Update the next recorded neighbor with the provided numbers
*
* This only increments the statistics if the length of the l2-address of the retrieved record
* is non-zero. see also @ref netstats_nb_record. The numbers indicate the number of transmissions
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sSee

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack, will fix

(netif_hdr->flags & GNRC_NETIF_HDR_FLAGS_MULTICAST)) {
gnrc_netdev->dev->stats.tx_mcast_count++;
#ifdef MODULE_NETSTATS_NEIGHBOR
DEBUG("l2 stats: Destination is multicast or unicast, NULL recorded");
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are you missing a \n here?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes :(

(GNRC_NETIF_HDR_FLAGS_BROADCAST | GNRC_NETIF_HDR_FLAGS_MULTICAST)) {
gnrc_netdev->dev->stats.tx_mcast_count++;
#ifdef MODULE_NETSTATS_NEIGHBOR
DEBUG("l2 stats: Destination is multicast or unicast, NULL recorded");
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, \n here?


#define ENABLE_DEBUG (0)
#include "debug.h"
//static char addr_str[30];
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can be removed?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, yes

@bergzand bergzand added the State: waiting for other PR State: The PR requires another PR to be merged first label Nov 11, 2017
@bergzand
Copy link
Copy Markdown
Member Author

@cgundogan Thanks for the (initial) review. I noticed that this PR was missing the "waiting for" tag. I've addressed your comments in #6873.

@stale
Copy link
Copy Markdown

stale bot commented Aug 10, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Aug 10, 2019
@stale stale bot closed this Sep 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: network Area: Networking State: stale State: The issue / PR has no activity for >185 days State: waiting for other PR State: The PR requires another PR to be merged first Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants