Has anyone done any performance tests to see what throughput can be achieved using RIOT?
I would be interested to know if the Cortex M0+ is powerful enough to sustain 250Kb/s TCP over 6lowpan/802.15.4.
Does RIOT have any mechanism to measure CPU usage?
- Simon
Hi Simon,
Throughput will be highly dependent upon the RF environment and what transceiver you are using. The M0+ most likely has enough power to do it under ideal conditions, but retransmissions due to collisions will limit the effective bandwidth.
You can use 900 mhz and 2.4 ghz transceivers with 15.4. ~900 is significantly less crowded but lower theoretical bandwidth. The Atmel 212B is 900 Mhz and specs 1000 kbps as the max air data rate.
Which transceiver are you using?
Craig Younkins
Hi Craig,
We have a 802.15.4 transceiver that is capable of 250kbps. We are thinking of using this with a Cortex M0+ but wanted to make sure that the M0+ would have the processing power to handle the 802.15.4/6lowpan/ipv6 stack at a datarate of 250kbps.
I just wondered if anyone had done any datarate measurements on existing development boards using the Cortex M0+?
Hi,
I think our only m0+/802.15.4 board is the samr21-xpro and there are problems with the current/old network stack because of its memory demands. That said: which protocol on top of IP are you interested in? I assume you want to ignore RPL and any other side-tasks for this evaluation?
Cheers, Ludwig
Hi Ludwig!
I think our only m0+/802.15.4 board is the samr21-xpro and there are problems with the current/old network stack because of its memory demands.
I haven't followed the discussion about RPL and UDP on the SAMR21 lately, but doesn't these memory problems only exist when using with RPL in storing mode and the default routing table size of up to 128 nodes?
Cheers, Oleg
Yes I tried to compile the rpl_udp example for the samr21-xpro but it did not have enough RAM. Even with RPL in non-storing mode and a very small routing table it would not fit.
Ultimately we would be looking to run UDP/RPL/COAP on top of the IPv6/6lowpan/802.15.4 stack.
For the evaluation just UDP would be fine to give me an idea if a M0+ would be fast enough.
Is the size of RAM/flash for RIOT likely to increase? Currently building the rpl_udp example results in 109K text+data, 37K bss. We were thinking of going for a M0+ with 128KB flash and 64KB RAM but this does not leave much room for expansion.
Am I correct in thinking that the IPv6/6lowpan/UDP/TCP/RPL stacks are fairly complete but there is quite a bit missing at the 802.15.4 mac layer such as beacons and security? I assume this will increase the code size of RIOT?
Thanks
Simon
Hi Simon!
Yes I tried to compile the rpl_udp example for the samr21-xpro but it did not have enough RAM. Even with RPL in non-storing mode and a very small routing table it would not fit.
Well, in non-storing you basically don't need any routing table (except for the root node), but still it sounds weird to me that it doesn't fit. I guess some optimization could be doable but...
Ultimately we would be looking to run UDP/RPL/COAP on top of the IPv6/6lowpan/802.15.4 stack.
For the evaluation just UDP would be fine to give me an idea if a M0+ would be fast enough.
Is the size of RAM/flash for RIOT likely to increase? Currently building the rpl_udp example results in 109K text+data, 37K bss. We were thinking of going for a M0+ with 128KB flash and 64KB RAM but this does not leave much room for expansion.
Hopefully and most likely the contrary will be the case. As the current network stack could definitely need quite some memory optimizations and wastes a lot of memory by many memcpy operations, we decided to completely redesign it, in order come up with a much slimmer solution. (Apart of having identified other drawbacks of the old solution.)
This new stack should definitely fit on the 32 kB RAM of the SAMr21 including UDP/RPL/CoAP, but I cannot give any concrete numbers by now. Hauke, Martine, can you give some rough numbers for the current state of the implementation?
Another advantage of the redesigned network stack will be its configurability. The current version, for example, always expects the default minimum MTU for IPv6 of 1280 bytes and thus reserves this once in the outgoing and once for the incoming buffer.
For more information on the new network stack, see our paper on [1502.01968] Old Wine in New Skins? Revisiting the Software Architecture for IP Network Stacks on Constrained IoT Devices and the minutes from the meeting in February: minutes network task force feb 2015 · RIOT-OS/RIOT Wiki · GitHub
There is also most of the functionality already out there on Github as Pull Requests.
Am I correct in thinking that the IPv6/6lowpan/UDP/TCP/RPL stacks are fairly complete but there is quite a bit missing at the 802.15.4 mac layer such as beacons and security? I assume this will increase the code size of RIOT?
Yes, this assumption is mostly correct. The biggest limitations for the upper layer stack are: - In the current version, 6LoWPAN and IPv6 are mostly entangled and therefore IPv6 cannot be used standalone. - Without support for multiple radios on one board, similar to Contiki, the border router will work only over stdio over a serial port (and haven't been tested for quite a while). - Only the basic TCP feature set is implemented. Due to memory constraints, the window size is fixed to one.
However, as I said before, we can expect rather a _de_creasing code size for the new version of the network stack, eliminating these shortcomings.
Cheers, Oleg