1 <html devsite> 2 <head> 3 <title>Batching</title> 4 <meta name="project_path" value="/_project.yaml" /> 5 <meta name="book_path" value="/_book.yaml" /> 6 </head> 7 <body> 8 <!-- 9 Copyright 2017 The Android Open Source Project 10 11 Licensed under the Apache License, Version 2.0 (the "License"); 12 you may not use this file except in compliance with the License. 13 You may obtain a copy of the License at 14 15 http://www.apache.org/licenses/LICENSE-2.0 16 17 Unless required by applicable law or agreed to in writing, software 18 distributed under the License is distributed on an "AS IS" BASIS, 19 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 20 See the License for the specific language governing permissions and 21 limitations under the License. 22 --> 23 24 25 26 <h2 id="what_is_batching">What is batching?</h2> 27 <p>Batching refers to storing sensor events in a hardware FIFO before reporting 28 them through the <a href="hal-interface.html">HAL</a> instead of reporting them immediately.</p> 29 <p>Batching can enable significant power savings by preventing the SoC from waking 30 up to receive each event. Instead, the events can be grouped and processed 31 together. </p> 32 <p>The bigger the FIFOs, the more power can be saved. Implementing batching is an 33 exercise of trading off hardware memory for reduced power consumption.</p> 34 <p>Batching happens when a sensor possesses a hardware FIFO 35 (<code>sensor_t.fifoMaxEventCount > 0</code>) and we are in one of two situations:</p> 36 <ul> 37 <li> <code>max_report_latency > 0</code>, meaning the sensor events for this specific sensor can 38 be delayed up to <code>max_report_latency</code> before being reported through the HAL. </li> 39 <li> or the SoC is in suspend mode and the sensor is a non-wake-up sensor, meaning 40 events must be stored while waiting for the SoC to wake up. </li> 41 </ul> 42 <p>See the paragraph on the <a 43 href="hal-interface.html#batch_sensor_flags_sampling_period_maximum_report_latency">HAL 44 batch function</a> for more details.</p> 45 <p>The opposite of batching is the continuous operation, where events are not 46 buffered, meaning they are reported immediately. Continuous operation 47 corresponds to:</p> 48 <ul> 49 <li> when <code>max_report_latency = 0</code> and the events can be delivered to the application, 50 meaning 51 <ul> 52 <li> the SoC is awake </li> 53 <li> or the sensor is a wake-up sensor </li> 54 </ul> 55 </li> 56 <li> or when the sensor doesnt have a hardware FIFO (<code>sensor_t.fifoMaxEventCount = 57 0</code>), in which case 58 <ul> 59 <li> the events are reported if the SoC is awake or the sensor is a wake-up sensor </li> 60 <li> the events are lost when the SoC is asleep and the sensor is not a wake-up 61 sensor </li> 62 </ul> 63 </li> 64 </ul> 65 <h2 id="wake-up_fifos_and_non-wake-up_fifos">Wake-up FIFOs and non-wake-up FIFOs</h2> 66 <p>Sensor events from <a href="suspend-mode.html#wake-up_sensors">wake-up 67 sensors</a> must be stored into a wake-up FIFO. There can be one wake-up FIFO 68 per sensor, or, more commonly, one big shared wake-up FIFO where events from all wake-up 69 sensors are interleaved. Other options are also possible, with for example some 70 wake-up sensors having a dedicated FIFO, and the rest of the wake-up sensors 71 all sharing the same one.</p> 72 <p>Similarly, sensor events from <a 73 href="suspend-mode.html#non-wake-up_sensors">non-wake-up sensors</a> must be 74 stored into a non-wake-up FIFOs, and there can be one or several 75 non-wake-up FIFOs.</p> 76 <p>In all cases, wake-up sensor events and non-wake-up sensor events cannot be 77 interleaved into the same FIFO. Wake-up events go in wake-up FIFOs, and 78 non-wake-up events go in non-wake-up FIFOs.</p> 79 <p>For the wake-up FIFO, the one big shared FIFO design provides the best power 80 benefits. For the non-wake-up FIFO, there is no preference between the one big 81 shared FIFO and several small reserved FIFOs. See <a 82 href="#fifo_allocation_priority">FIFO allocation priority</a> for suggestions 83 on how to dimension each FIFO.</p> 84 <h2 id="behavior_outside_of_suspend_mode">Behavior outside of suspend mode</h2> 85 <p>When the SoC is awake (not in suspend mode), the events can be stored 86 temporarily in their FIFO, as long as they are not delayed by more than 87 <code>max_report_latency</code>.</p> 88 <p>As long as the SoC doesnt enter the suspend mode, no event shall be dropped or 89 lost. If internal hardware FIFOs is getting full before <code>max_report_latency</code> 90 elapsed, then events are reported at that point to ensure that no event is 91 lost.</p> 92 <p>If several sensors share the same FIFO and the <code>max_report_latency</code> of one of 93 them elapses, all events from the FIFO are reported, even if the 94 <code>max_report_latency</code> of the other sensors didnt elapse yet. The general goal is 95 to reduce the number of times batches of events must be reported, so as soon as 96 one event must be reported, all events from all sensors can be reported.</p> 97 <p>For example, if the following sensors are activated:</p> 98 <ul> 99 <li> accelerometer batched with <code>max_report_latency</code> = 20s </li> 100 <li> gyroscope batched with <code>max_report_latency</code> = 5s </li> 101 </ul> 102 <p>Then the accelerometer batches can be reported at the same time the gyroscope 103 batches are reported (every 5 seconds), even if the accelerometer and the 104 gyroscope do not share the same FIFO.</p> 105 <h2 id="behavior_in_suspend_mode">Behavior in suspend mode</h2> 106 <p>Batching is particularly beneficial when wanting to collect sensor data in the 107 background without keeping the SoC awake. Because the sensor drivers and HAL 108 implementation are not allowed to hold a wake-lock*, the SoC can enter the 109 suspend mode even while sensor data is being collected.</p> 110 <p>The behavior of sensors while the SoC is suspended depends on whether the 111 sensor is a wake-up sensor. See <a 112 href="suspend-mode.html#wake-up_sensors">Wake-up sensors</a> for some 113 details.</p> 114 <p>When a non-wake-up FIFO fills up, it must wrap around and behave like a 115 circular buffer, overwriting older events: the new events replace the old ones. 116 <code>max_report_latency</code> has no impact on non-wake-up FIFOs while in suspend mode.</p> 117 <p>When a wake-up FIFO fills up, or when the <code>max_report_latency</code> of one of the 118 wake-up sensor elapsed, the hardware must wake up the SoC and report the data.</p> 119 <p>In both cases (wake-up and non-wake-up), as soon as the SoC comes out of 120 suspend mode, a batch is produced with the content of all FIFOs, even if 121 <code>max_report_latency</code> of some sensors didnt elapse yet. This minimizes the risk 122 of having to wake-up the SoC again soon if it goes back to suspend. Hence, it 123 minimizes power consumption.</p> 124 <p>*One notable exception of drivers not being allowed to hold a wake lock is when 125 a wake-up sensor with <a href="report-modes.html#continuous">continuous 126 reporting mode</a> is activated with <code>max_report_latency</code> < 1 127 second. In that case, the driver can hold a wake lock because the SoC would 128 anyway not have the time to enter the suspend mode, as it would be awoken by 129 a wake-up event before reaching the suspend mode.</p> 130 <h2 id="precautions_to_take_when_batching_wake-up_sensors">Precautions to take when batching wake-up sensors</h2> 131 <p>Depending on the device, it might take a few milliseconds for the SoC to 132 entirely come out of suspend and start flushing the FIFO. Enough head room must 133 be allocated in the FIFO to allow the device to entirely come out of suspend 134 without the wake-up FIFO overflowing. No events shall be lost, and the 135 <code>max_report_latency</code> must be respected.</p> 136 <h2 id="precautions_to_take_when_batching_non-wake-up_on-change_sensors">Precautions to take when batching non-wake-up on-change sensors</h2> 137 <p>On-change sensors only generate events when the value they are measuring is 138 changing. If the measured value changes while the SoC is in suspend mode, 139 applications expect to receive an event as soon as the SoC wakes up. Because of 140 this, batching of <a href="suspend-mode.html#non-wake-up_sensors">non-wake-up</a> on-change sensor events must be performed carefully if the sensor shares its 141 FIFO with other sensors. The last event generated by each on-change sensor must 142 always be saved outside of the shared FIFO so it can never be overwritten by 143 other events. When the SoC wakes up, after all events from the FIFO have been 144 reported, the last on-change sensor event must be reported.</p> 145 <p>Here is a situation we want to avoid:</p> 146 <ol> 147 <li> An application registers to the non-wake-up step counter (on-change) and the 148 non-wake-up accelerometer (continuous), both sharing the same FIFO </li> 149 <li> The application receives a step counter event step_count=1000 steps </li> 150 <li> The SoC goes to suspend </li> 151 <li> The user walks 20 steps, causing step counter and accelerometer events to be 152 interleaved, the last step counter event being step_count = 1020 steps </li> 153 <li> The user doesnt move for a long time, causing accelerometer events to continue 154 accumulating in the FIFO, eventually overwriting every step_count event in the 155 shared FIFO </li> 156 <li> SoC wakes up and all events from the FIFO are sent to the application </li> 157 <li> The application receives only accelerometer events and thinks that the user 158 didnt walk (bad!) </li> 159 </ol> 160 <p>By saving the last step counter event outside of the FIFO, the HAL can report 161 this event when the SoC wakes up, even if all other step counter events were 162 overwritten by accelerometer events. This way, the application receives 163 step_count = 1020 steps when the SoC wakes up.</p> 164 <h2 id="implementing_batching">Implementing batching</h2> 165 <p>Batching cannot be emulated in software. It must be implemented entirely in 166 hardware, with hardware FIFOs. In particular, it cannot be implemented on the 167 SoC, for example in the HAL implementation, as this would be 168 counter-productive. The goal here is to save significant amounts of power. 169 Batching must be implemented without the aid of the SoC, which should be 170 allowed to be in suspend mode during batching.</p> 171 <p><code>max_report_latency</code> can be modified at any time, in particular while the 172 specified sensor is already enabled; and this shall not result in the loss of 173 events.</p> 174 <h2 id="fifo_allocation_priority">FIFO allocation priority</h2> 175 <p>On platforms in which hardware FIFO size is limited, the system designers may 176 have to choose how much FIFO to reserve for each sensor. To help with this 177 choice, here is a list of applications made possible when batching is 178 implemented on the different sensors.</p> 179 <h3 id="high_value_low_power_pedestrian_dead_reckoning">High value: Low power pedestrian dead reckoning</h3> 180 <p>Target batching time: 1 to 10 minutes</p> 181 <p>Sensors to batch:</p> 182 <ul> 183 <li> Wake-up Step detector </li> 184 <li> Wake-up Game rotation vector at 5Hz </li> 185 <li> Wake-up Barometer at 5Hz </li> 186 <li> Wake-up Uncalibrated Magnetometer at 5Hz </li> 187 </ul> 188 <p>Batching this data allows performing pedestrian dead reckoning while letting 189 the SoC go to suspend.</p> 190 <h3 id="high_value_medium_power_intermittent_activity_gesture_recognition">High value: Medium power intermittent activity/gesture recognition</h3> 191 <p>Target batching time: 3 seconds</p> 192 <p>Sensors to batch: Non-wake-up Accelerometer at 50Hz</p> 193 <p>Batching this data allows periodically recognizing arbitrary activities and 194 gestures without having to keep the SoC awake while the data is collected.</p> 195 <h3 id="medium_value_medium_power_continuous_activity_gesture_recognition">Medium value: Medium power continuous activity/gesture recognition</h3> 196 <p>Target batching time: 1 to 3 minutes</p> 197 <p>Sensors to batch: Wake-up Accelerometer at 50Hz</p> 198 <p>Batching this data allows continuously recognizing arbitrary activities and 199 gestures without having to keep the SoC awake while the data is collected.</p> 200 <h3 id="medium-high_value_interrupt_load_reduction">Medium-high value: Interrupt load reduction</h3> 201 <p>Target batching time: < 1 second</p> 202 <p>Sensors to batch: any high frequency sensor, usually non-wake-up.</p> 203 <p>If the gyroscope is set at 240Hz, even batching just 10 gyro events can reduce 204 the number of interrupts from 240/second to 24/second.</p> 205 <h3 id="medium_value_continuous_low_frequency_data_collection">Medium value: Continuous low frequency data collection</h3> 206 <p>Target batching time: 1 to 10 minutes</p> 207 <p>Sensors to batch:</p> 208 <ul> 209 <li> Wake-up barometer at 1Hz, </li> 210 <li> Wake-up humidity sensor at 1Hz </li> 211 <li> Other low frequency wake-up sensors at similar rates </li> 212 </ul> 213 <p>Allows creating monitoring applications at low power.</p> 214 <h3 id="medium-low_value_continuous_full-sensors_collection">Medium-low value: Continuous full-sensors collection</h3> 215 <p>Target batching time: 1 to 10 minutes</p> 216 <p>Sensors to batch: all wake-up sensors, at high frequencies</p> 217 <p>Allows full collection of sensor data while leaving the SoC in suspend mode. 218 Only to consider if FIFO space is not an issue.</p> 219 220 </body> 221 </html> 222
