ICEr: An Intermittent Computing Environment Based on a Run-Time Module for Energy-Harvesting IoT Devices with NVRAM

Round 1

Reviewer 1 Report

The manuscript titled ‘ICEr: Intermittent Computing Environment based on a Run-time Module for Energy-harvesting IoT Devices with NVRAM’ proposes a methodology names Intermittent Computing Environment ased on a run-time module (ICEr) for dynamically controls and manages an application which works with harvested energy. ICEr comprises an energy checker and a controller and the energy checker measures the energy state of a device at run-time, ad the controller controls and manages the operations by considering the energy state and memory state together to minimize time and energy overhead.

The work is well written, interesting, and complete; only some minor aspects should be clarified by the authors:

• Row 148. you write that ‘FRAM, a representative NVRAM, is more expensive then EEPROM’, please give a quantification of this difference of cost.
• Row 265. How the sufficient energy level is set? Is it necessary that the device preliminarily executes the application? Please clarify this aspect.
• Rows 285-295. Please clarify the comparator functioning, with a scheme or a table or a figure. It is too twisted the text in the lines indicated.
• In Fig. 6 it is difficult to distinguish between Restore and Wakeup; could you modify the figure?
• Finally, in paragraph 4.3, testing the utilization to real IoT applications, ICEr methodology permits to reduce up to 7.3% the energy than Hibernus; but, what about the overall differences between the two methodologies taking into account all the aspects (simplicity, cost, components, size, flexibility, etc)

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

The presented work proposes a low-power intermittent computing environment that dynamically controls and manages an application in an IoT wireless node powered by harvested energy. The proposed concept is based on a hardware solution comprising an energy checker and a controller that are respectively used to available energy level monitoring (the energy checker) and to ensure properly performing Backup, Restore, Sleep, and Wakeup, according to the energy state and memory state (the controller).

The performance of the proposed solution and its benefits in terms of energy efficiency and in providing forward progress in application execution was demonstrated in practice for seven energy scenarios and for a few benchmark applications.

However, in the revised version of the manuscript the following issues should be given more clarification:

1) if the energy checker and the controller are hardware units, then what they are made of and how they look like in real autonomous IoT node working without any SDK environment? How the current and the energy are measured?

2) it is recommended to describe more precisely how the energy state indicated from the energy checker is “translated” directly on the operation of the controller, and then how it exactly performs Backup, Restore, Sleep, and Wakeup according to the energy state and memory state;

3) the sentence in lines 262-263 - “The predefined energy levels have the sufficient energy level and the insufficient energy level”, sounds unclear. Please, clarify what exactly “the predefined energy levels have the sufficient energy level” means?

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 3 Report

This paper provides a good explanation of the need for intermittent computing technologies within the context of edge devices with limited access to energy, relying on sporadic energy harvesting. The authors claim the proposed model addresses some of the limitations of the state of the art; namely, lack of consideration for factors beyond energy state, such as memory state.

In Figure 2, it is not immediately clear what the difference is between the two problems. I recommend authors use different programs in (a) and (b) to make the distinction more explicit

Section 2.3.1 does a good job of highlighting the challenges of programming models for intermittent computing.

Section 2.3.2, however, is not as convincing. The authors claim compiler models are not aware of the target application, thus can insert unnecessary checkpoints that throttle performance and power consumption. I'm not convinced by this statement. Whilst it may be true for the particular referenced works, it is not an inherent drawback of compiler models: it is probably simple (at least feasible) to include the same application/environment knowledge used in the proposed work in a compiler-friendly format that can be used to guide automated checkpoint insertion. In fact, the following section on JIT techniques illustrates precisely this point. Substantial improvement is required here to further illustrate the differences, and ideally that would be reflected in the experimental results.
Some comparisons to the JIT model also need to be clarified. Authors claim JIT models do not take into account memory state. However, later when discussing the proposed approach: "ICEr always copies the entire image when the application’s operating state is copied
to the non-volatile memory." This seems to be a "worst case" approach, where the energy overhead of writing the entire state to memory is non-negligible, and contradicts some other claims: e.g., "It minimizes Backup and Restore through the energy state check and avoids unnecessary operations through the memory state check.". With memory access typically being the power bottleneck, isn't trading unnecessary operations for excessive memory writes a bad thing?

I'm quite pleased with the experimental section; experiments are thorough and convincing. As a "wish list", I'd like to see at least one example of another model (e.g., programming model such as Chain or Alpaca) compared, but I'm aware this corresponds to substantial effort.

Overall, I really enjoyed this manuscript. I think some care and consideration must be put into revising the comparison with related work, especially when it comes to the compiler model, and I hope these comments can help the authors improve their manuscript before publication.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf