Task Scheduling to Constrain Peak Current Consumption in Wearable Healthcare Sensors
, Balazs Janko 1, Terence Hui 2, William S. Harwin 1, Nilanjan Dey 3, Daniel Díaz-Sánchez 4, Jin Wang 5 and Fuqian Shi 6Round 1
Reviewer 1 Report
The proposal of using an energy scheduler to optimize the power peaks in wearables by using RTOS based task scheduler is a very novel and nice approach. It is aligned with the trends in energy management (at any size/dimension), and face a problem hidden in small devices where the design was focused in low power but no power management in the way this paper presents.
The paper is clear, good references and state of the art. It's technically sound and sections are clearly presented.
Author Response
The proposal of using an energy scheduler to optimize the power peaks in wearables by using RTOS based task scheduler is a very novel and nice approach. It is aligned with the trends in energy management (at any size/dimension), and face a problem hidden in small devices where the design was focused in low power but no power management in the way this paper presents.
Author response: Thank you very much for your very supportive comment. Much appreciated.
The paper is clear, good references and state of the art. It's technically sound and sections are clearly presented.
Author response: Thank you very much for your very supportive the comment. We have worked very hard on the concept for 2 years and delighted that you think the paper is clearly presented.
Reviewer 2 Report
This paper proposes a task scheduling approach to constrain peak power consumption in wearable healthcare sensors with real time operating systems. The idea is interesting and novel and therefore the work can potentially be a good contribution to the field of battery-operated sensor systems in general. The manuscript is well-written except for a couple typos here and there. It can be a good contribution for the MDPI Electronics Journal. However, in its current version, the manuscript does not validate the proposed idea. Therefore, I suggest a major revision including an in-depth analysis of the proposed idea:
1. The modification to the scheduler presented in Section III is very general and should be elaborated. For instance, one sensor in different scenarios or different sensors having different requirements can be considered.
2. The justification of the idea in pages 1-through-5 looks promising. However, the authors should validate some (if not all) of the potential improvements mentioned in the Discussion section (e.g., long battery life, reduced battery dimensions, temperature reduction, carbon footprint), by performing actual measurements, for instance on their SPHERE wearable, and comparing the performance metrics using the original and modified RTOS task schedulers.
Author Response
This paper proposes a task scheduling approach to constrain peak power consumption in wearable healthcare sensors with real time operating systems. The idea is interesting and novel and therefore the work can potentially be a good contribution to the field of battery-operated sensor systems in general.
Author response: Thank you very much for your very supportive comment. We think it is novel and can have a big impact on small devices.
The manuscript is well-written except for a couple typos here and there.
Author response: Thank you, we have all contributed to the paper and the paper has been proof read by all of us and even my wife and daughters! We found a few typos and have changed 22 places in the manuscript to correct for typos or to improve the English. Thank you.
It can be a good contribution for the MDPI Electronics Journal.
Author response: Thank you, we have selected MDPI Electronics, not only for is prestige but also the special issue on low-power wearable devices.
However, in its current version, the manuscript does not validate the proposed idea. Therefore, I suggest a major revision including an in-depth analysis of the proposed idea:
1. The modification to the scheduler presented in Section III is very general and should be elaborated. For instance, one sensor in different scenarios or different sensors having different requirements can be considered.
Author response: Thank you. We needed to be general as we cannot change the underlying scheduler code ourselves. Our paper is to show that if the scheduler code was to be modified then there are advantages to be made – it is a position paper with an attempt to try and get people thinking.
We do present the sensor in different scenarios, the first used RTOS in a basic monitoring scenario where no problem was identified, and the second scenario where the problem was identified and fixed using our idea.
The authors like your suggestion of different scenarios. As the SPHERE wearable was designed to be low-power, we only have 3 sources of large current – the FLASH, BLE transmission and the SoC being “on”. Our second scenario in the paper covers the case of all three, but what we did not show was the scenario of the peak current actually being “fixed” – constrained by the scheduler proposal. In order to address this, we have added text and new figure 6 to show that the FLASH write process has been successfully delayed to avoid the peak in current – the whole purpose of the work.
2. The justification of the idea in pages 1-through-5 looks promising.
Author response: Thank you. We have tried to take the reader though a journey of how we discovered the problem and its solution.
…However, the authors should validate some (if not all) of the potential improvements mentioned in the Discussion section (e.g., long battery life, reduced battery dimensions, temperature reduction, carbon footprint), by performing actual measurements, for instance on their SPHERE wearable, and comparing the performance metrics using the original and modified RTOS task schedulers.
Author response: Thank you. Yes, you are very correct. We have “lumped” the advantages together with our enthusiasm and on reflection the paper does seem to over claim, we apologize. We have addressed the text accordingly:
Concerning battery size, our argument was that if we reduce the peak current that can be drawn from the battery then the battery size could been smaller. We have removed this comment as size is really a function of capacity not peak current.
Concerning battery life, we don’t actually make any claim that our system allows for a battery to have longer life. Indeed our system does not at all save power, but rather reduce the peak power by speaking the power drawn across time. The abstract mentions battery life – but that is just to set the scene of the paper and what the majority of the research field aims at.
Concerning temperature, we stated that some systems aim to reduce the power in order to constrain temperature in data centers (though power management algorithms in general). On reflection this can be confusing – one moment discussing the large power data centers, and the other end of the spectrum low-power wearable devices. Of course, looking at power, then spreading current will still consume the same power anyway! Thank you for the comment and we have removed the reference to temperature. As known, in large power systems temperate can spike due to speak currents, but we do not get such problems in low-power systems due to ambient temperature.
Concerning carbon footprint, that was an aspirational comment and discussed in the context of data centers, so we have removed the comment.
Thanks for your suggestions.
Reviewer 3 Report
In this paper a discussion about task scheduling to constrain peak current is presented. The paper is well written and well structured but it displays serious flaws that, in my opinion, do not make advisable its publication in the present form.
1) In the introduction several papers presenting different scheduling strategies are discussed. However none of them is tried in the platform presented in the paper. In general, schedulers which minimize power consumption usually consider current as the metric to constraint. Similarly, minimizing average power consumption usually involves the limitation of the peak power consumption of the load, as it can be seen in the following reference.
P. Chowdhury and C. Chakrabarti, "Static task-scheduling algorithms for battery-powered DVS systems," in IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 13, no. 2, pp. 226-237, Feb. 2005.
I would recommend authors to review how the load peak current is managed in the published works.
2) More than 80% of the paper novelty is on a wearable platform "SPHERE" in which RTOS is not used and where the solution for the peak current is "ad-hoc". Based on these, section 3 proposes a modification of RTOS task parameters. This view of the problema and solution is quite bizarre. Section 3 would need a previous work on RTOS inside the "SPHERE" platform and a real solution presented for the peak current based on a real RTOS rescheduling.
3) Flash peak current usually appears some delay after the flash write operation, cause by internal's flash state machine. Therefore, task scheduling should include latency parameters, etc. otherwise the current overlap may not disappear. These points should also be discussed when presenting constraint task scheduling.
Author Response
In this paper a discussion about task scheduling to constrain peak current is presented. The paper is well written and well structured but it displays serious flaws that, in my opinion, do not make advisable its publication in the present form.
Author response: Thank you very much for your very supportive comment.
1) In the introduction several papers presenting different scheduling strategies are discussed. However none of them is tried in the platform presented in the paper. In general, schedulers which minimize power consumption usually consider current as the metric to constraint.
Author response: Thank you very much for your comment. Yes, you are correct. The majority of the literature considers strategies to minimize the overall power which by definition is derived from current and time. In our case, our system had issues when drawing too much current, so we presented the ideas of spreading large peaks of current across time. This does not reduce the power, but rather constrains the peak power drawn at any point in time. It is this concept is what we claim is novel and as such propose changes to RTOS design to enable it to happen.
Similarly, minimizing average power consumption usually involves the limitation of the peak power consumption of the load, as it can be seen in the following reference.
P. Chowdhury and C. Chakrabarti, "Static task-scheduling algorithms for battery-powered DVS systems," in IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 13, no. 2, pp. 226-237, Feb. 2005.
I would recommend authors to review how the load peak current is managed in the published works.
Author response: Thank you for this reference. It was very interesting. That reference tries to reduce the peak in their “battery profile” in order to maximize the battery residual charge which is different in our case of scheduling to reduce the peak current drawn from the battery at a given point in time by spreading the current over time. Also, their system used DVS which is only available in high-end CPU’s and not available in the low-power CPU field. Again thank you for the reference, we have added it and discussed the paper in our text.
2) More than 80% of the paper novelty is on a wearable platform "SPHERE" in which RTOS is not used and where the solution for the peak current is "ad-hoc". Based on these, section 3 proposes a modification of RTOS task parameters. This view of the problema and solution is quite bizarre. Section 3 would need a previous work on RTOS inside the "SPHERE" platform and a real solution presented for the peak current based on a real RTOS rescheduling.
Author response: Thank you for this comment. When creating the SPHERE wearable, we found an issue and used research to fix the issue. In the paper we needed to discuss the SPHERE background and then present our solution. The SHPERE wearable does use RTOS – always as TI’s BLE requires it, and this was stated in the paper:
“The wearable was programed using an RTOS [25].”
The solution for solving the peak current is novel – we use the scheduler to spread the large peak of current into two (or more) smaller peaks at different points in time. The system works. To emphasis the concept further, we have added Figure 6 following the scheduler discussion to show the results in practice.
Sadly we cannot comment on why you feel the solution is bizarre. The problem was real, and our solution is to modify existing scheduler concepts to incorporate task current into the task scheduler processes which we demonstrate works. We do use real RTOS scheduling in the SPHERE wearable. As stated in this concept paper, we cannot actually change the task scheduler code ourselves, so we propose what could be achieved.
3) Flash peak current usually appears some delay after the flash write operation, cause by internal's flash state machine. Therefore, task scheduling should include latency parameters, etc. otherwise the current overlap may not disappear. These points should also be discussed when presenting constraint task scheduling.
Author response: Thank you – that is a wonderful idea! There is a delay between the FLASH write command and the actual FLASH write process, yes. However, this is in the order of 1 RTOS ‘tick’ of 10 us. As such the current increase is seen immediately in the “eyes” of the RTOS.
The ideal of latency parameters is really interesting and is an excellent basis for further work. However, this is your idea, not ours, and we do not want to steal your idea. Hence, out of respect to you, we have not mentioned it in the paper. What we have mentioned in the paper is that the FLASH write process itself is a very short-duration task so we can approximate that the current is static in the whole FLASH write process. Thank you.
Thanks for your suggestions.
Round 2
Reviewer 2 Report
My following comment, which is the reason for my suggestion of "major revision" is not addressed in the revised manuscript: "...by performing actual measurements, for instance on their SPHERE wearable, and comparing the performance metrics using the original and modified RTOS task schedulers."
Author Response
Dear Reviewer,
Thank you for your hard work reviewing the paper again. It is much appreciated.
We will try and address your recent comment:
“My following comment, which is the reason for my suggestion of "major revision" is not addressed in the revised manuscript: "...by performing actual measurements, for instance on their SPHERE wearable, and comparing the performance metrics using the original and modified RTOS task schedulers."
In the first version of paper, we presented actual results, measured from the actual SPHERE wearable, figures 1, 2 and 3 are actual measurements. They show the actual current drawn from the battery when the SPHERE wearable processes an IRQ from the IMU. Figure 3 showed the problem that we addressed where a large peak of current could be seen when two asynchronous tasks both caused a large amount of current to be drawn and this caused brownouts in certain cases due to the Buck convertor voltage dipping (as described in the text above figure 3.) Therefore all of the paper uses actual measurements. The measurements are taken from the data-logging feature from a scope.
To address your initial reviewer comment “The modification to the scheduler presented in Section III is very general and should be elaborated. For instance, one sensor in different scenarios or different sensors having different requirements can be considered”, we wrote in our reviewer response that we cannot change the scheduler code, we use the TI scheduler for the TI chip and customers don’t get access to the scheduler code. Hence, we discussed that we present a position paper to show what would happen if the scheduler was modified and the advantages that can be gained when modifying. However, you rightly pointed out we did not show the “results” in the initial paper, so to address this we added a new figure (figure 5) to show what would happen if the scheduler was in a position to delay the task as we propose and as can be seen from figure 5 there is no large peak, but rather smaller peaks separated in time, thus addressing the issue.
In our response, we also wrote that we addressed your quite correct comments regarding battery size, etc.
As stated, we cannot compare “actual scheduler” with “modified scheduler” as we do not have access to the underling scheduler code. What we present, is the before case (figure 3) and the after case when applying the concept of our proposal (figure 5). While we cannot change the scheduler, we implemented a task to write to the FLASH and we ran that task delayed after the BLE ADV as exactly what a modified scheduler would do.
Therefore, we believe that we have addressed your concern. In the original version we presented actual measurements, on their SPHERE wearable, but you were correct we did not show the results of implementing our proposal. As proposed we modified the paper to incorporate all your comments and added figure 5 to show actual results of the modified version.
Respectfully, we believe that we have addressed all of your comments in the first review. We present actual before and after results, both using RTOS, both on the SPHERE wearable. If we have misunderstood your request then we apologize but we currently respectfully believe our paper does fully address all of your comments and shows what you have quire rightly asked for.
Thank you.
Reviewer 3 Report
I recognize that I missunderstood a key part of the paper in the first version. Essentially that the SPHERE platform was running an RTOS, instead I though that was running an ad-hoc programing. Now it is clear and I consider the contribution of the paper significant in this direction. Thank you to the authors for all the clarifications.
Just a couple of typos I have seen:
Line 233: "In" order to create...
Line 236: The task scheduler can "then" construct...
Author Response
Dear Reviewer,
Thank you for your hard work reviewing the paper again and finding two typos. I have corrected them.
We appreciate your comments and it means a lot that you now think the paper is significant.
Again thanks.
Round 3
Reviewer 2 Report
Authors have addressed my comments.
