Re: [riot-devel] Association time in mobile RPL/6lowpan networks

2015-05-22 Thread Landsmann, Martin
Hi Adam, hi Cenk,

 Has anyone tested the amount of time it takes for a node (full or reduced 
 function) to join an RPL routed 6lowpan network?
Not a particular range, but I can confirm that the time varies until a RPL 
topology converges in whole, and that it varies for a single node to join.

Regarding the further discussion, I'm not convinced if we should send periodic 
DIS messages.
Even if they get lost, DIOs are disseminated repeatedly by all nodes in a DODAG 
when trickle fires [1].
Concerning LLNs I don't like to send additional packets periodically at all.
In my opinion it just drains the energy of a node with small to no benefit.
Even if a node is not answered with a DIO directly when sending a DIS, 
eventually a DIO will arrive from a neighbor node (assuming one is present).

Resetting the trickle timer from applications sounds like a good opportunity 
for debugging and testing things.
Just as Adam I also think such feature should be only available for debugging 
and testing.
Resetting the trickle timer in normal operation from an application sounds 
for me like interfering with the routing protocol,
or even attacking the topology ;)

 ...anything like this should be runtime configurable as long as such 
 configurability doesn't adversely effect battery life, code 
 complexity/readability, etcetera in a massive way
I think the most impacting problem with such approach is that every convenience 
function/structure we provide will produce more bytes used on the ROM and RAM.
RPL is used on nodes with few kB RAM and ROM and it must share this room with a 
network stack and further productive applications.
Concerning this, I obviously vote for compile time configuration :)

These are just some thoughts and my personal opinion.

Best regards,
Martin

[1] https://tools.ietf.org/html/rfc6550#section-8.3

Von: devel [devel-boun...@riot-os.org] im Auftrag von Adam Hunt 
[voxa...@gmail.com]
Gesendet: Freitag, 22. Mai 2015 07:09
An: RIOT OS kernel developers
Betreff: Re: [riot-devel] Association time in mobile RPL/6lowpan networks


I like the idea of sending periodic DIS messages but I absolutely believe that 
it should not only be optional but  that it be configurable at runtime.

Honestly, I am a firm believe in the idea that virtually anything like this 
should be runtime configurable as long as such configurability doesn't 
adversely effect battery life, code complexity/readability, etcetera in a 
massive way. This is something that Linus has absolutely right with Linux; 
policy don't shouldn't be written in kernel space stone; everyone had different 
requirements and altering the way an OS behaves from the (sensible) defaults 
shouldn't require altering mainline code and maintaining a private branch if at 
all possible. Ideally everything should be runtime configurable, if that's not 
possible it should be configurable at boot, if that for some reason isn't 
possible it should be compile time configurable.

On Wed, May 20, 2015, 11:53 PM Joakim Gebart 
joakim.geb...@eistec.semailto:joakim.geb...@eistec.se wrote:

On May 21, 2015 8:37 AM, Cenk Gündogan 
cenk.guendo...@fu-berlin.demailto:cenk.guendo...@fu-berlin.de wrote:

 Hey Adam,

 I am currently adopting RPL to our new network stack and while doing so,
 I also added sane functionalities which were plainly missing in the old 
 implementation.
 This also includes sending a DIS when initializing RPL for the first time.
 However,  I am just now realizing that such a DIS can get lost in our typical 
 LLN case - it may make sense to send a DIS periodically until a DIO is 
 received?
 Does anyone has an opinion on this?

Good idea, as long as the periodic interval is large enough to not waste power 
or cause interruptions in normal traffic if there is no other rpl node on the 
network.


 Forcing a DIS from userspace sounds like a good feature. It may help in 
 testing/debuging the dodag tree interactively.
 I also thought about reseting the trickle timer from userspace to enforce 
 DIOs.

+1 for this. It would be nice to have some shell commands to call these 
functions too.

Best regards,
/Joakim


 Cheers,
 Cenk


 On 21.05.2015 04:36, Adam Hunt wrote:

 That's great. Is there any way to force a node to send a DIS message from 
 userspace?


 On Wed, May 20, 2015, 5:34 PM Oleg Hahm 
 oliver.h...@inria.frmailto:oliver.h...@inria.fr wrote:

 Hi Adam!

  Has anyone tested the amount of time it takes for a node (full or reduced
  function) to join an RPL routed 6lowpan network? I realize that it's very
  likely to vary quite a bit depending on the network, I'm just curious if
  anyone has an approximate range.

 As you said: it depends quite a bit on the network and the parameters. Since
 nodes on the current RPL implementation won't send proactively DIS messages
 and the interval of sending DIOs increases, it will usually take just a 
 couple
 of seconds if you try to join the network right after bootup, but can take
 

Re: [riot-devel] API proficiency levels

2015-05-22 Thread Joakim Gebart
Did the discussion about redundant parameter validations and DEVELHELP die?

I like the idea of getting rid of some redundant input validation. For
example, if you are internally using spi_transfer_byte to provide
spi_transfer_regs, then if the SPI device is valid for the first byte
transferred, then it is probably going to be valid for the rest of the
bytes in the same function call chain.

There was some discussion about null pointer checks in a PR or a
mailing list thread but I did not find it when I did a brief search.

Best regards,
Joakim Gebart
www.eistec.se


On Wed, Mar 25, 2015 at 5:02 PM, Kaspar Schleiser kas...@schleiser.de wrote:
 Hey,

 On 03/25/2015 11:12 AM, Hauke Petersen wrote:

 in general I like the idea, one problem I see is however, that is not
 always clear, to which level an API belongs (e.g. the GPIO API is
 definitely used also by high-level application programmers, while still
 belonging to the low-level peripheral drivers...).

 We could mark certain functions / parts of an API as advanced in the docs
 and provide safe alternatives.

 Seriously, it hurts to not be able to work around 10 redundant
 checks whether an int coming from flash is a correct SPI device...


 Kaspar
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Neighbor Discovery finalized for now

2015-05-22 Thread Martine Lenders
Dear routing RIOTers,

with PR #3049 I'm happy to announce that I finally finished my work on
vanilla IPv6 neighbor discovery. Please test it extensive. Things still
missing is the Redirect Function [2] which I see as optional for now
(because it is not really needed for LoWPANs) and the 6LoWPAN optimization
[3] (which I will provide as a follow-up PR next around week).

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/3049
[2] https://tools.ietf.org/html/rfc4861#section-8
[3] https://tools.ietf.org/html/rfc6775
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel