Batching

Apa itu batching?

Batching mengacu pada buffering peristiwa sensor di hub sensor dan/atau FIFO perangkat keras sebelum melaporkan peristiwa melalui Sensor HAL . Lokasi di mana peristiwa sensor disangga (hub sensor dan/atau FIFO perangkat keras) disebut sebagai "FIFO" di halaman ini. Saat pengelompokan peristiwa sensor tidak aktif, peristiwa sensor segera dilaporkan ke HAL Sensor jika tersedia.

Batching dapat mengaktifkan penghematan daya yang signifikan dengan hanya membangunkan prosesor aplikasi utama (AP), yang menjalankan Android, ketika banyak peristiwa sensor siap untuk diproses, alih-alih membangunkannya untuk setiap peristiwa individu. Potensi penghematan daya secara langsung berkorelasi dengan jumlah peristiwa yang dapat disangga oleh hub sensor dan/atau FIFO: ada potensi penghematan daya yang lebih besar jika lebih banyak peristiwa dapat dikelompokkan. Batching memanfaatkan penggunaan memori berdaya rendah untuk mengurangi jumlah bangun AP berdaya tinggi.

Batching hanya dapat terjadi ketika sensor memiliki FIFO perangkat keras dan/atau dapat menyangga kejadian di dalam hub sensor. Dalam kedua kasus tersebut, sensor harus melaporkan jumlah maksimum peristiwa yang dapat dikelompokkan sekaligus melalui SensorInfo.fifoMaxEventCount .

Jika sensor memiliki ruang yang dicadangkan dalam FIFO, sensor harus melaporkan jumlah peristiwa yang dicadangkan melalui SensorInfo.fifoReservedEventCount . Jika FIFO didedikasikan untuk sensor, maka SensorInfo.fifoReservedEventCount adalah ukuran FIFO. Jika FIFO dibagi di antara beberapa sensor, nilai ini mungkin nol. Kasus penggunaan yang umum adalah mengizinkan sensor untuk menggunakan seluruh FIFO jika itu adalah satu-satunya sensor yang aktif. Jika beberapa sensor aktif, maka setiap sensor dijamin ruang untuk setidaknya peristiwa SensorInfo.fifoReservedEventCount di FIFO. Jika hub sensor digunakan, jaminan dapat diterapkan melalui perangkat lunak.

Peristiwa sensor dikelompokkan dalam situasi berikut:

• Latensi laporan maksimum sensor saat ini lebih besar dari nol, yang berarti bahwa peristiwa sensor dapat ditunda hingga latensi laporan maksimum sebelum dilaporkan melalui HAL.
• AP dalam mode tunda dan sensornya adalah sensor non-bangun. Dalam hal ini, peristiwa tidak boleh membangunkan AP dan harus disimpan sampai AP bangun.

Jika sensor tidak mendukung batching dan AP tertidur, hanya peristiwa sensor bangun yang dilaporkan ke AP dan peristiwa non-bangun tidak boleh dilaporkan ke AP.

Parameter batch

Dua parameter yang mengatur perilaku batching adalah sampling_period_ns dan max_report_latency_ns . sampling_period_ns menentukan seberapa sering peristiwa sensor baru dihasilkan, dan max_report_latency_ns menentukan berapa lama hingga peristiwa tersebut harus dilaporkan ke HAL Sensor.

sampling_period_ns

Arti parameter sampling_period_ns bergantung pada mode pelaporan sensor yang ditentukan:

• Berkelanjutan: sampling_period_ns adalah laju pengambilan sampel, yang berarti laju peristiwa yang dihasilkan.
• Saat berubah: sampling_period_ns membatasi laju pengambilan sampel peristiwa, artinya peristiwa dihasilkan tidak lebih cepat dari setiap nanodetik sampling_period_ns . Periode bisa lebih lama dari sampling_period_ns jika tidak ada peristiwa yang dihasilkan dan nilai terukur tidak berubah untuk periode yang lama. Untuk detail selengkapnya, lihat mode pelaporan saat berubah .
• Satu-shot: sampling_period_ns diabaikan. Ini tidak berpengaruh.
• Khusus: Untuk detail tentang bagaimana sampling_period_ns digunakan untuk sensor khusus, lihat Jenis Sensor .

Untuk informasi selengkapnya tentang dampak sampling_period_ns dalam mode yang berbeda, lihat Mode pelaporan .

Untuk sensor kontinu dan saat berubah:

• jika sampling_period_ns kurang dari SensorInfo.minDelay , maka implementasi HAL harus diam-diam menjepitnya ke max(SensorInfo.minDelay, 1ms) . Android tidak mendukung pembuatan acara di lebih dari 1000 Hz.
• jika sampling_period_ns lebih besar dari SensorInfo.maxDelay , maka implementasi HAL harus secara diam-diam memotongnya ke SensorInfo.maxDelay .

Sensor fisik terkadang memiliki batasan pada kecepatan yang dapat dijalankan dan keakuratan jamnya. Untuk menjelaskan hal ini, frekuensi pengambilan sampel yang sebenarnya dapat berbeda dari frekuensi yang diminta selama memenuhi persyaratan dalam tabel di bawah ini.

max_report_latency_ns

max_report_latency_ns menetapkan waktu maksimum dalam nanodetik, di mana peristiwa dapat ditunda dan disimpan di FIFO perangkat keras sebelum dilaporkan melalui HAL saat AP terjaga.

Nilai nol menandakan bahwa peristiwa harus dilaporkan segera setelah diukur, baik melewatkan FIFO sama sekali, atau mengosongkan FIFO segera setelah satu peristiwa dari sensor hadir.

Misalnya, akselerometer yang diaktifkan pada 50 Hz dengan max_report_latency_ns=0 akan memicu interupsi 50 kali per detik saat AP terjaga.

Ketika max_report_latency_ns>0 , peristiwa sensor tidak perlu dilaporkan segera setelah terdeteksi. Mereka dapat disimpan sementara di FIFO dan dilaporkan dalam kumpulan, selama tidak ada peristiwa yang tertunda lebih dari max_report_latency_ns nanodetik. Ini berarti bahwa semua peristiwa sejak batch sebelumnya dicatat dan dikembalikan sekaligus. Ini mengurangi jumlah interupsi yang dikirim ke AP dan memungkinkan AP untuk beralih ke mode daya yang lebih rendah (idle) saat sensor menangkap dan mengelompokkan data.

Setiap acara memiliki stempel waktu yang terkait dengannya. Menunda waktu saat peristiwa dilaporkan tidak memengaruhi stempel waktu peristiwa. Stempel waktu harus akurat dan sesuai dengan waktu terjadinya peristiwa secara fisik, bukan waktu dilaporkan.

Mengizinkan peristiwa sensor disimpan sementara di FIFO tidak mengubah perilaku mengirimkan peristiwa ke HAL; peristiwa dari sensor yang berbeda dapat disisipkan dan semua peristiwa dari sensor yang sama diatur waktunya.

Acara bangun dan tidak bangun

Peristiwa sensor dari sensor bangun harus disimpan dalam satu atau beberapa FIFO bangun. Desain umum adalah memiliki FIFO bangun tunggal, besar, bersama di mana peristiwa dari semua sensor bangun disisipkan. Atau, Anda dapat memiliki satu FIFO pengaktifan per sensor atau memiliki FIFO khusus untuk sensor pengaktifan tertentu dan FIFO bersama untuk sensor pengaktifan lainnya.

Demikian pula, peristiwa sensor dari sensor non-bangun harus disimpan dalam satu atau lebih FIFO non-bangun.

Dalam semua kasus, peristiwa sensor bangun dan peristiwa sensor non-bangun tidak dapat disisipkan dalam FIFO yang sama. Peristiwa bangun harus disimpan dalam FIFO bangun, dan peristiwa tidak bangun harus disimpan dalam FIFO tidak bangun.

Untuk FIFO bangun, desain FIFO tunggal, besar, dan bersama memberikan manfaat daya terbaik. Untuk FIFO non-bangun, FIFO tunggal, besar bersama dan beberapa desain FIFO cadangan kecil memiliki karakteristik daya yang serupa. Untuk saran lebih lanjut tentang cara mengonfigurasi setiap FIFO, lihat prioritas alokasi FIFO .

Perilaku di luar mode penangguhan

Saat AP terjaga (tidak dalam mode tunda), acara disimpan sementara di FIFO selama tidak ditunda lebih dari max_report_latency .

Selama AP tidak masuk ke mode suspend, tidak ada event yang akan dijatuhkan atau hilang. Jika FIFO internal menjadi penuh sebelum max_report_latency berlalu, peristiwa dilaporkan pada saat itu untuk memastikan bahwa tidak ada peristiwa yang hilang.

Jika beberapa sensor berbagi FIFO yang sama dan max_report_latency salah satunya berlalu, semua kejadian dari FIFO akan dilaporkan, meskipun max_report_latency dari sensor lain belum berlalu. Ini mengurangi berapa kali kumpulan peristiwa dilaporkan. Ketika satu peristiwa harus dilaporkan, semua peristiwa dari semua sensor dilaporkan.

Misalnya, jika sensor berikut diaktifkan:

• akselerometer dirangkai dengan max_report_latency = 20s
• giroskop di-batch dengan max_report_latency = 5s

Kumpulan akselerometer dilaporkan pada saat yang sama kumpulan giroskop dilaporkan (setiap 5 detik), bahkan jika akselerometer dan giroskop tidak berbagi FIFO yang sama.

Perilaku dalam mode tunda

Batching sangat bermanfaat untuk mengumpulkan data sensor di latar belakang tanpa membuat AP tetap terjaga. Karena driver sensor dan implementasi HAL tidak diizinkan untuk menahan wake-lock*, AP dapat memasuki mode tunda bahkan saat data sensor sedang dikumpulkan.

Perilaku sensor saat AP ditangguhkan tergantung pada apakah sensor tersebut merupakan sensor bangun. Untuk detail selengkapnya, lihat Sensor pengaktifan .

Ketika FIFO non-bangun terisi, ia harus membungkus dan berperilaku seperti buffer melingkar, menimpa acara lama dengan acara baru menggantikan yang lama. max_report_latency tidak berdampak pada FIFO non-bangun saat dalam mode tunda.

Ketika FIFO bangun terisi, atau ketika max_report_latency dari salah satu sensor bangun berlalu, perangkat keras harus membangunkan AP dan melaporkan data.

Dalam kedua kasus (wake-up dan non-wake-up), segera setelah AP keluar dari mode suspend, batch diproduksi dengan konten semua FIFO, bahkan jika max_report_latency dari beberapa sensor belum berlalu. Ini meminimalkan risiko AP harus bangun lagi segera setelah kembali ke mode tunda dan, oleh karena itu, meminimalkan konsumsi daya.

*Satu pengecualian penting dari pengemudi yang tidak diizinkan untuk menahan penguncian layar saat bangun adalah ketika sensor bangun dengan mode pelaporan berkelanjutan diaktifkan dengan max_report_latency <1 detik. Dalam hal ini, pengemudi dapat menahan wake lock karena AP tidak punya waktu untuk masuk ke mode suspend, karena akan dibangunkan oleh peristiwa bangun sebelum mencapai mode suspend.

Tindakan pencegahan yang harus diambil saat mengelompokkan sensor bangun

Bergantung pada perangkatnya, mungkin perlu beberapa milidetik agar Titik Akses keluar dari mode tunda sepenuhnya dan mulai membilas FIFO. Ruang kepala yang cukup harus dialokasikan di FIFO untuk memungkinkan perangkat keluar dari mode tunda tanpa FIFO bangun yang meluap. Tidak ada acara yang akan hilang, dan max_report_latency harus dihormati.

Tindakan pencegahan yang harus dilakukan saat mengelompokkan sensor perubahan yang tidak bangun

Sensor saat berubah hanya menghasilkan peristiwa ketika nilai yang mereka ukur berubah. Jika nilai terukur berubah saat AP dalam mode tunda, aplikasi berharap untuk menerima peristiwa segera setelah AP bangun. Karena itu, pengelompokan peristiwa sensor yang tidak aktif saat perubahan harus dilakukan dengan hati-hati jika sensor berbagi FIFO-nya dengan sensor lain. Peristiwa terakhir yang dihasilkan oleh setiap sensor perubahan harus selalu disimpan di luar FIFO bersama sehingga tidak pernah dapat ditimpa oleh peristiwa lain. Ketika AP bangun, setelah semua peristiwa dari FIFO telah dilaporkan, peristiwa sensor perubahan terakhir harus dilaporkan.

Berikut adalah situasi yang harus dihindari:

1. Aplikasi mendaftar ke penghitung langkah non-bangun (on-change) dan akselerometer non-bangun (terus menerus), keduanya berbagi FIFO yang sama.
2. Aplikasi menerima peristiwa penghitung langkah step_count=1000 steps >.
3. AP pergi untuk menangguhkan.
4. Pengguna berjalan 20 langkah, menyebabkan peristiwa penghitung langkah dan akselerometer disisipkan, peristiwa penghitung langkah terakhir adalah step_count = 1020 steps .
5. Pengguna tidak bergerak untuk waktu yang lama, menyebabkan peristiwa akselerometer terus terakumulasi di FIFO, akhirnya menimpa setiap peristiwa step_count di FIFO bersama.
6. AP bangun dan semua acara dari FIFO dikirim ke aplikasi.
7. Aplikasi hanya menerima peristiwa akselerometer dan menganggap bahwa pengguna tidak berjalan.

Dengan menyimpan peristiwa penghitung langkah terakhir di luar FIFO, HAL dapat melaporkan peristiwa ini saat AP bangun, bahkan jika semua peristiwa penghitung langkah lainnya ditimpa oleh peristiwa akselerometer. Dengan cara ini, aplikasi menerima step_count = 1020 steps saat AP bangun.

Menerapkan batching

Untuk menghemat daya, batching harus dilaksanakan tanpa bantuan AP, dan AP harus dibiarkan ditangguhkan selama batching.

Jika batching dilakukan di hub sensor, penggunaan daya hub sensor harus diminimalkan.

Latensi laporan maksimum dapat dimodifikasi kapan saja, khususnya saat sensor yang ditentukan sudah diaktifkan; dan ini seharusnya tidak mengakibatkan hilangnya acara.

Prioritas alokasi FIFO

Pada platform di mana FIFO perangkat keras dan/atau ukuran buffer hub sensor terbatas, perancang sistem mungkin harus memilih berapa banyak FIFO yang akan dicadangkan untuk setiap sensor. Untuk membantu dengan pilihan ini, berikut adalah daftar kemungkinan aplikasi saat batching diimplementasikan pada sensor yang berbeda.

Nilai tinggi: Perhitungan mati pejalan kaki berdaya rendah

Target waktu batching: 1 hingga 10 menit

Sensor untuk batch:

• Detektor langkah bangun
• Vektor rotasi game bangun pada 5 Hz
• Barometer bangun pada 5 Hz
• Magnetometer bangun yang tidak dikalibrasi pada 5 Hz

Batching data ini memungkinkan melakukan perhitungan mati pejalan kaki sambil membiarkan AP pergi untuk ditangguhkan.

Nilai tinggi: Aktivitas intermiten/pengenalan gerakan daya sedang

Target waktu batching: 3 detik

Sensor untuk batch: Akselerometer non-bangun pada 50 Hz

Batching data ini memungkinkan secara berkala mengenali aktivitas dan gerakan arbitrer tanpa harus membuat AP tetap terjaga saat data dikumpulkan.

Nilai sedang: Aktivitas berkelanjutan/pengenalan gerakan daya sedang

Target waktu batching: 1 hingga 3 menit

Sensor untuk batch: Akselerometer bangun pada 50 Hz

Batching data ini memungkinkan terus menerus mengenali aktivitas dan gerakan arbitrer tanpa harus membuat AP tetap terjaga saat data dikumpulkan.

Nilai sedang-tinggi: Pengurangan beban interupsi

Target waktu batching: <1 detik

Sensor untuk batch: semua sensor frekuensi tinggi, biasanya non-bangun.

Jika giroskop diatur pada 240 Hz, bahkan batching hanya 10 peristiwa gyro dapat mengurangi jumlah interupsi dari 240/detik menjadi 24/detik.

Nilai sedang: Pengumpulan data frekuensi rendah terus menerus

Target waktu batching: 1 hingga 10 menit

Sensor untuk batch:

• Barometer bangun pada 1 Hz
• Sensor kelembaban bangun pada 1 Hz
• Sensor bangun frekuensi rendah lainnya dengan kecepatan yang sama

Memungkinkan pembuatan aplikasi pemantauan dengan daya rendah.

Nilai sedang-rendah: Koleksi sensor penuh berkelanjutan

Target waktu batching: 1 hingga 10 menit

Sensor untuk dikumpulkan: Semua sensor bangun, pada frekuensi tinggi

Memungkinkan pengumpulan penuh data sensor saat meninggalkan Titik Akses dalam mode tunda. Hanya pertimbangkan jika ruang FIFO tidak menjadi masalah.