Re: [riot-devel] Dynamic radio power scaling in RIOT
Hi, On 06/27/2017 09:42 AM, Peter Kietzmann wrote: > Hi Koen, > > thanks for your explanations! Are you aware of the FIT IoT-lab testbed? > > https://www.iot-lab.info/ > > This should give you access to several hundred iotlab-m3 nodes which are > equipped with an at86rf231. There is also one site with some tens of > samr21-xpros, equipped with an at86rf233. You just made my day, I thought they only had nodes with the at86rf231 > Would be great if you keep me/us informed about your results :-). I should have some slides with results this friday. Regards, Koen > > Best > Peter > > On 26.06.2017 12:36, Koen wrote: >> Hi, >> >> For now this is all quite proof of concept. I haven't had the time to >> measure the actual power saving. >> >> There are still a few problems that limit the actual power saving. The >> way I've implemented it now, only transmit power is limited. Before a >> transmission, the radio power is configured, and almost immediately >> after, the transmit power is set to full power again. This way L2 ACK >> frames are always send at full power and the power scale algorithms of >> nodes don't affect each other. Furthermore, if I have to believe the >> datasheets, the radio's seem to also consume comparable current when in >> RX-mode. For now, until I've confirmed the actual power draw of the >> radio, I think the most benefits are in the reduced transmission range >> and thus reduced interference between nodes. >> >> The other limitation is that my implementation depends on the radio >> reporting the frame retries. At least the mrf24j40 and the at86rf233 >> support this. I don't know about the kw2xrf. The other variants of the >> at86rf2xx don't seem to support reporting the frame retries, they only >> report whether at least an ACK was received or not. >> >> I don't have any plans of repeated tests in network topologies at the >> moment, mostly because I don't have a large enough network at my >> disposal. I'm still trying to get at least repeatable results from my >> small setup, but random interference makes this difficult. Any proposals >> for this are welcome. I'd love to have some larger tests on node >> interaction here. In the future I'd like to try to have RPL minimize >> power consumption as a route metric.> >> The actual power scaling algorithms I've implemented are based on TCP >> congestion control. TCP congestion control also has the goal of >> approaching a limit where loss occurs when the limit is passed. Two >> algorithm are implemented: A "Reno" style additive increase, >> multiplicative decrease and a "Cubic" approach style function. As soon >> as I have some results where I can actually compare both algorithm I'll >> share them here. >> >> One of the other ideas for algorithms I've had so far was a PID kind of >> control loop where a predefined ETX value is used as a setpoint. This >> way a configurable amount of loss versus power saving might be achieved. >> If somebody has a different proposal for an algorithm, I'd like to know. >> I'm currently trying to use only ETX or other already known values >> instead of a negotiating algorithm to keep the implementation compatible >> with different nodes and/or operating systems. >> >> Regards, >> Koen >> >> On 06/23/2017 09:03 AM, Peter Kietzmann wrote: >>> Hi Koen, >>> >>> awesome! IMO this is interesting work and I'd like to push this forward, >>> at least to use it myself at some point in time, though I can't promise >>> an in-depth review so soon -> let's start polishing "later". >>> >>> Did you already start measurements of the actual consumption saving of a >>> node? Do you plan to evaluate your approach in different network >>> topologies? >>> >>> Cheers >>> Peter >>> >>> On 22.06.2017 22:00, Koen Zandberg wrote: Hello, For a small research project as a part of my study, I did some research on the effectiveness of dynamic radio output scaling. The general idea is that to save power, the radio has to transmit at only the power required to reach the destination. For the research I wanted to build a practical setup instead of a simulation as one of the research goals. The setup I've build works by estimating the minimum required powered and using layer 2 acks (or the lack thereof) as feedback. At this point I have a mostly working power scaling proof of concept implemented in RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg which is a measurement of a number of packets. The blue dots is an ETX estimation measured based on the feedback from the radio module. The Red line is the power configured for that packet. As visible, power is scaled down until a stable level is reached. Power keeps oscillating around this level until a lot of interference is noticed, then the power sweeps back up. The merit of this whole idea is that it should both save the node power, but when implemented correctly also improve
Re: [riot-devel] Dynamic radio power scaling in RIOT
Hi Koen, thanks for your explanations! Are you aware of the FIT IoT-lab testbed? https://www.iot-lab.info/ This should give you access to several hundred iotlab-m3 nodes which are equipped with an at86rf231. There is also one site with some tens of samr21-xpros, equipped with an at86rf233. Would be great if you keep me/us informed about your results :-). Best Peter On 26.06.2017 12:36, Koen wrote: > Hi, > > For now this is all quite proof of concept. I haven't had the time to > measure the actual power saving. > > There are still a few problems that limit the actual power saving. The > way I've implemented it now, only transmit power is limited. Before a > transmission, the radio power is configured, and almost immediately > after, the transmit power is set to full power again. This way L2 ACK > frames are always send at full power and the power scale algorithms of > nodes don't affect each other. Furthermore, if I have to believe the > datasheets, the radio's seem to also consume comparable current when in > RX-mode. For now, until I've confirmed the actual power draw of the > radio, I think the most benefits are in the reduced transmission range > and thus reduced interference between nodes. > > The other limitation is that my implementation depends on the radio > reporting the frame retries. At least the mrf24j40 and the at86rf233 > support this. I don't know about the kw2xrf. The other variants of the > at86rf2xx don't seem to support reporting the frame retries, they only > report whether at least an ACK was received or not. > > I don't have any plans of repeated tests in network topologies at the > moment, mostly because I don't have a large enough network at my > disposal. I'm still trying to get at least repeatable results from my > small setup, but random interference makes this difficult. Any proposals > for this are welcome. I'd love to have some larger tests on node > interaction here. In the future I'd like to try to have RPL minimize > power consumption as a route metric.> > The actual power scaling algorithms I've implemented are based on TCP > congestion control. TCP congestion control also has the goal of > approaching a limit where loss occurs when the limit is passed. Two > algorithm are implemented: A "Reno" style additive increase, > multiplicative decrease and a "Cubic" approach style function. As soon > as I have some results where I can actually compare both algorithm I'll > share them here. > > One of the other ideas for algorithms I've had so far was a PID kind of > control loop where a predefined ETX value is used as a setpoint. This > way a configurable amount of loss versus power saving might be achieved. > If somebody has a different proposal for an algorithm, I'd like to know. > I'm currently trying to use only ETX or other already known values > instead of a negotiating algorithm to keep the implementation compatible > with different nodes and/or operating systems. > > Regards, > Koen > > On 06/23/2017 09:03 AM, Peter Kietzmann wrote: >> Hi Koen, >> >> awesome! IMO this is interesting work and I'd like to push this forward, >> at least to use it myself at some point in time, though I can't promise >> an in-depth review so soon -> let's start polishing "later". >> >> Did you already start measurements of the actual consumption saving of a >> node? Do you plan to evaluate your approach in different network >> topologies? >> >> Cheers >> Peter >> >> On 22.06.2017 22:00, Koen Zandberg wrote: >>> Hello, >>> >>> For a small research project as a part of my study, I did some research >>> on the effectiveness of dynamic radio output scaling. The general idea >>> is that to save power, the radio has to transmit at only the power >>> required to reach the destination. For the research I wanted to build a >>> practical setup instead of a simulation as one of the research goals. >>> >>> The setup I've build works by estimating the minimum required powered >>> and using layer 2 acks (or the lack thereof) as feedback. At this point >>> I have a mostly working power scaling proof of concept implemented in >>> RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg >>> which is a measurement of a number of packets. The blue dots is an ETX >>> estimation measured based on the feedback from the radio module. The Red >>> line is the power configured for that packet. As visible, power is >>> scaled down until a stable level is reached. Power keeps oscillating >>> around this level until a lot of interference is noticed, then the power >>> sweeps back up. >>> >>> The merit of this whole idea is that it should both save the node power, >>> but when implemented correctly also improve the total throughput of the >>> network. This last point because nodes transmit with less power, thus >>> causing less interference with nodes further away. >>> >>> If there is interest in having this feature merged in mainline RIOT-os, >>> I'm willing to work on this to make sure that the
