बैचिंग क्या है?
बैचिंग से तात्पर्य सेंसर हब और/या हार्डवेयर फीफो में सेंसर घटनाओं को सेंसर एचएएल के माध्यम से रिपोर्ट करने से पहले बफरिंग सेंसर ईवेंट से है। वह स्थान जहां सेंसर ईवेंट बफ़र किए जाते हैं (सेंसर हब और/या हार्डवेयर FIFO) को इस पृष्ठ पर "FIFO" के रूप में संदर्भित किया जाता है। जब सेंसर ईवेंट बैचिंग सक्रिय नहीं होती है, तो उपलब्ध होने पर सेंसर ईवेंट की तुरंत सेंसर HAL को रिपोर्ट की जाती है।
बैचिंग केवल मुख्य एप्लिकेशन प्रोसेसर (एपी) को जगाकर महत्वपूर्ण बिजली बचत को सक्षम कर सकता है, जो एंड्रॉइड चलाता है, जब कई सेंसर ईवेंट संसाधित होने के लिए तैयार होते हैं, बजाय इसे प्रत्येक व्यक्तिगत घटना के लिए जगाने के। संभावित बिजली बचत सीधे उन घटनाओं की संख्या से संबंधित है जो सेंसर हब और/या फीफो बफर कर सकते हैं: यदि अधिक घटनाओं को बैच किया जा सकता है तो बिजली बचत की अधिक संभावना है। बैचिंग हाई-पावर एपी वेक-अप की संख्या को कम करने के लिए लो-पावर मेमोरी के उपयोग का लाभ उठाता है।
बैचिंग तभी हो सकती है जब सेंसर के पास हार्डवेयर FIFO हो और/या सेंसर हब के भीतर ईवेंट को बफर कर सके। किसी भी स्थिति में, सेंसर को उन घटनाओं की अधिकतम संख्या की रिपोर्ट करनी चाहिए जिन्हें एक बार में SensorInfo.fifoMaxEventCount
के माध्यम से बैच किया जा सकता है।
यदि किसी सेंसर के पास FIFO के भीतर स्थान आरक्षित है, तो सेंसर को SensorInfo.fifoReservedEventCount
के माध्यम से आरक्षित घटनाओं की संख्या की रिपोर्ट करनी चाहिए। यदि FIFO सेंसर को समर्पित है, तो SensorInfo.fifoReservedEventCount
FIFO के आकार का है। यदि FIFO को कई सेंसरों के बीच साझा किया जाता है, तो यह मान शून्य हो सकता है। एक सामान्य उपयोग का मामला सेंसर को पूरे फीफो का उपयोग करने की अनुमति देना है यदि यह एकमात्र सक्रिय सेंसर है। यदि एकाधिक सेंसर सक्रिय हैं, तो प्रत्येक सेंसर को FIFO में कम से कम SensorInfo.fifoReservedEventCount
ईवेंट के लिए स्थान की गारंटी दी जाती है। यदि सेंसर हब का उपयोग किया जाता है, तो सॉफ़्टवेयर के माध्यम से गारंटी लागू की जा सकती है।
सेंसर ईवेंट निम्न स्थितियों में बैच किए जाते हैं:
- सेंसर की वर्तमान अधिकतम रिपोर्ट विलंबता शून्य से अधिक है, जिसका अर्थ है कि सेंसर घटनाओं को एचएएल के माध्यम से रिपोर्ट किए जाने से पहले अधिकतम रिपोर्ट विलंबता तक विलंबित किया जा सकता है।
- AP सस्पेंड मोड में है और सेंसर नॉन-वेक-अप सेंसर है। इस मामले में, घटनाओं को एपी को नहीं जगाना चाहिए और एपी के जागने तक संग्रहीत किया जाना चाहिए।
यदि कोई सेंसर बैचिंग का समर्थन नहीं करता है और AP सो रहा है, तो AP को केवल वेक-अप सेंसर ईवेंट की सूचना दी जाती है और AP को नॉन-वेक-अप ईवेंट की सूचना नहीं दी जानी चाहिए।
बैचिंग पैरामीटर
बैचिंग के व्यवहार को नियंत्रित करने वाले दो पैरामीटर हैं sample_period_ns और max_report_latency_ns । sampling_period_ns
निर्धारित करता है कि कितनी बार एक नया सेंसर ईवेंट उत्पन्न होता है, और max_report_latency_ns
यह निर्धारित करता है कि सेंसर एचएएल को घटना की रिपोर्ट कब तक की जानी चाहिए।
नमूनाकरण_अवधि_एनएस
sampling_period_ns
पैरामीटर का मतलब निर्दिष्ट सेंसर के रिपोर्टिंग मोड पर निर्भर करता है:
- सतत:
sampling_period_ns
नमूना दर है, जिसका अर्थ है कि जिस दर पर घटनाएं उत्पन्न होती हैं। - ऑन-चेंज:
sampling_period_ns
घटनाओं की सैंपलिंग दर को सीमित करता है, जिसका अर्थ है कि इवेंट हरsampling_period_ns
नैनोसेकंड से अधिक तेजी से उत्पन्न नहीं होते हैं। यदि कोई घटना उत्पन्न नहीं होती है और मापा मान लंबी अवधि के लिए नहीं बदलते हैं, तो अवधिsampling_period_ns
से अधिक लंबी हो सकती है। अधिक विवरण के लिए, ऑन-चेंज रिपोर्टिंग मोड देखें। - एक-शॉट:
sampling_period_ns
पर ध्यान नहीं दिया जाता है। इसका कोई प्रभाव नहीं है। - विशेष: विशेष सेंसरों के लिए
sampling_period_ns
का उपयोग कैसे किया जाता है, इसके विवरण के लिए, सेंसर प्रकार देखें।
विभिन्न मोड में sampling_period_ns
के प्रभाव के बारे में अधिक जानकारी के लिए, रिपोर्टिंग मोड देखें।
निरंतर और ऑन-चेंज सेंसर के लिए:
- यदि
sampling_period_ns
SensorInfo.minDelay
से कम है, तो HAL कार्यान्वयन को चुपचाप इसेmax(SensorInfo.minDelay, 1ms)
से जोड़ देना चाहिए। एंड्रॉइड 1000 हर्ट्ज से अधिक की घटनाओं की पीढ़ी का समर्थन नहीं करता है। - यदि
sampling_period_ns
SensorInfo.maxDelay
से अधिक है, तो HAL कार्यान्वयन को इसेSensorInfo.maxDelay
में चुपचाप काट देना चाहिए।
भौतिक सेंसर की कभी-कभी उन दरों पर सीमाएं होती हैं जिन पर वे चल सकते हैं और उनकी घड़ियों की सटीकता। इसके लिए खाते में, वास्तविक नमूना आवृत्ति अनुरोधित आवृत्ति से भिन्न हो सकती है जब तक कि यह नीचे दी गई तालिका में आवश्यकताओं को पूरा करती है।
यदि अनुरोधित आवृत्ति है | तब वास्तविक आवृत्ति होनी चाहिए |
---|---|
न्यूनतम आवृत्ति से कम (<1/maxDelay) | न्यूनतम आवृत्ति के 90% और 110% के बीच |
न्यूनतम और अधिकतम आवृत्ति के बीच | अनुरोधित आवृत्ति के 90% और 220% के बीच |
अधिकतम आवृत्ति से ऊपर (>1/मिनट विलंब) | अधिकतम आवृत्ति के 90% और 110% के बीच, और 1100 हर्ट्ज से नीचे |
max_report_latency_ns
max_report_latency_ns
नैनोसेकंड में अधिकतम समय निर्धारित करता है, जिसके द्वारा घटनाओं को विलंबित किया जा सकता है और एपी के जागने के दौरान एचएएल के माध्यम से रिपोर्ट किए जाने से पहले हार्डवेयर फीफो में संग्रहीत किया जा सकता है।
शून्य का मान इंगित करता है कि जैसे ही घटनाओं को मापा जाता है, उन्हें रिपोर्ट किया जाना चाहिए, या तो फीफो को पूरी तरह से छोड़ देना, या जैसे ही सेंसर से एक घटना मौजूद है, फीफो को खाली कर देना चाहिए।
उदाहरण के लिए, max_report_latency_ns=0
के साथ 50 हर्ट्ज पर सक्रिय एक्सेलेरोमीटर एपी के जागने पर प्रति सेकंड 50 बार इंटरप्ट को ट्रिगर करेगा।
जब max_report_latency_ns>0
, सेंसर घटनाओं का पता लगते ही उन्हें रिपोर्ट करने की आवश्यकता नहीं होती है। उन्हें अस्थायी रूप से FIFO में संग्रहीत किया जा सकता है और बैचों में रिपोर्ट किया जा सकता है, जब तक कि कोई भी घटना max_report_latency_ns
नैनोसेकंड से अधिक विलंबित न हो। इसका मतलब है कि पिछले बैच के बाद से सभी घटनाओं को रिकॉर्ड किया गया है और एक ही बार में वापस कर दिया गया है। यह एपी को भेजे गए इंटरप्ट की मात्रा को कम करता है और एपी को कम पावर मोड (निष्क्रिय) पर स्विच करने की अनुमति देता है जबकि सेंसर डेटा कैप्चर और बैच कर रहा है।
प्रत्येक घटना के साथ एक टाइमस्टैम्प जुड़ा होता है। जिस समय पर किसी घटना की सूचना दी जाती है, उस समय में देरी करने से ईवेंट टाइमस्टैम्प प्रभावित नहीं होता है। टाइमस्टैम्प सटीक होना चाहिए और उस समय के अनुरूप होना चाहिए जिस समय घटना भौतिक रूप से हुई थी, न कि उस समय की रिपोर्ट की गई थी।
सेंसर ईवेंट को FIFO में अस्थायी रूप से संग्रहीत करने की अनुमति देने से HAL को ईवेंट सबमिट करने का व्यवहार संशोधित नहीं होता है; विभिन्न सेंसरों की घटनाओं को इंटरलीव किया जा सकता है और एक ही सेंसर से सभी घटनाओं को समय-आदेशित किया जाता है।
वेक-अप और नॉन-वेक-अप इवेंट्स
वेक-अप सेंसर से सेंसर ईवेंट को एक या अधिक वेक-अप FIFO में संग्रहीत किया जाना चाहिए। एक सामान्य डिज़ाइन एक एकल, बड़ा, साझा वेक-अप FIFO होना है जहाँ सभी वेक-अप सेंसर से ईवेंट इंटरलीव किए जाते हैं। वैकल्पिक रूप से, आपके पास प्रति सेंसर एक वेक-अप FIFO हो सकता है या विशेष वेक-अप सेंसर के लिए FIFO और बाकी वेक-अप सेंसर के लिए एक साझा FIFO हो सकता है।
इसी तरह, नॉन-वेक-अप सेंसर से सेंसर ईवेंट को एक या अधिक नॉन-वेक-अप FIFO में संग्रहित किया जाना चाहिए।
सभी मामलों में, वेक-अप सेंसर इवेंट और नॉन-वेक-अप सेंसर इवेंट को एक ही FIFO में इंटरलीव नहीं किया जा सकता है। वेक-अप ईवेंट को वेक-अप FIFO में संग्रहीत किया जाना चाहिए, और नॉन-वेक-अप ईवेंट को नॉन-वेक-अप FIFO में संग्रहीत किया जाना चाहिए।
वेक-अप फीफो के लिए, सिंगल, लार्ज, शेयर्ड फीफो डिजाइन सबसे अच्छा बिजली लाभ प्रदान करता है। नॉन-वेक-अप FIFO के लिए, एकल, बड़े साझा FIFO और कई छोटे आरक्षित FIFO डिज़ाइनों में समान शक्ति विशेषताएँ होती हैं। प्रत्येक FIFO को कॉन्फ़िगर करने के तरीके के बारे में अधिक सुझावों के लिए, FIFO आवंटन प्राथमिकता देखें।
सस्पेंड मोड के बाहर का व्यवहार
जब AP जाग रहा होता है (निलंबित मोड में नहीं), तब तक ईवेंट को FIFO में अस्थायी रूप से संग्रहीत किया जाता है, जब तक कि वे max_report_latency
से अधिक विलंबित न हों।
जब तक AP सस्पेंड मोड में प्रवेश नहीं करता है, तब तक कोई भी ईवेंट छोड़ा या खोया नहीं जाएगा। यदि max_report_latency
समाप्त होने से पहले आंतरिक FIFO पूर्ण हो जाते हैं, तो उस बिंदु पर घटनाओं की सूचना दी जाती है ताकि यह सुनिश्चित किया जा सके कि कोई भी घटना गुम न हो।
यदि कई सेंसर समान FIFO साझा करते हैं और उनमें से एक की max_report_latency
समाप्त हो जाती है, तो FIFO की सभी घटनाओं की रिपोर्ट की जाती है, भले ही अन्य सेंसर की max_report_latency
अभी तक समाप्त नहीं हुई हो। यह घटनाओं के बैचों की रिपोर्ट किए जाने की संख्या को कम करता है। जब एक घटना की सूचना दी जानी चाहिए, तो सभी सेंसर से सभी घटनाओं की सूचना दी जाती है।
उदाहरण के लिए, यदि निम्नलिखित सेंसर सक्रिय हैं:
- एक्सेलेरोमीटर
max_report_latency
= 20s . के साथ बैच किया गया - जाइरोस्कोप
max_report_latency
= 5s . के साथ बैच किया गया
एक्सेलेरोमीटर बैचों की रिपोर्ट उसी समय की जाती है जब जाइरोस्कोप बैचों की सूचना दी जाती है (हर 5 सेकंड में), भले ही एक्सेलेरोमीटर और जाइरोस्कोप एक ही फीफो को साझा न करें।
सस्पेंड मोड में व्यवहार
एपी को जगाए बिना बैकग्राउंड में सेंसर डेटा एकत्र करने के लिए बैचिंग विशेष रूप से फायदेमंद है। चूंकि सेंसर ड्राइवर और एचएएल कार्यान्वयन को वेक-लॉक* रखने की अनुमति नहीं है, सेंसर डेटा एकत्र किए जाने के दौरान भी एपी सस्पेंड मोड में प्रवेश कर सकता है।
एपी निलंबित होने पर सेंसर का व्यवहार इस बात पर निर्भर करता है कि सेंसर एक वेक-अप सेंसर है या नहीं। अधिक विवरण के लिए, वेक-अप सेंसर देखें।
जब एक नॉन-वेक-अप FIFO भर जाता है, तो उसे चारों ओर लपेटना चाहिए और एक गोलाकार बफर की तरह व्यवहार करना चाहिए, पुराने ईवेंट को पुराने ईवेंट की जगह नई ईवेंट के साथ ओवरराइट करना चाहिए। max_report_latency
का सस्पेंड मोड में रहते हुए नॉन-वेक-अप FIFO पर कोई प्रभाव नहीं पड़ता है।
जब एक वेक-अप FIFO भर जाता है, या जब किसी वेक-अप सेंसर की max_report_latency
समाप्त हो जाती है, तो हार्डवेयर को AP को जगाना होगा और डेटा की रिपोर्ट करनी होगी।
दोनों ही मामलों में (वेक-अप और नॉन-वेक-अप), जैसे ही AP सस्पेंड मोड से बाहर आता है, सभी FIFO की सामग्री के साथ एक बैच तैयार किया जाता है, भले ही कुछ सेंसरों की max_report_latency
अभी तक समाप्त नहीं हुई हो। यह एपी के सस्पेंड मोड में लौटने के तुरंत बाद फिर से जागने के जोखिम को कम करता है और इसलिए, बिजली की खपत को कम करता है।
*ड्राइवरों को वेक लॉक रखने की अनुमति नहीं देने का एक उल्लेखनीय अपवाद तब है जब निरंतर रिपोर्टिंग मोड वाला वेक-अप सेंसर max_report_latency
<1 सेकंड के साथ सक्रिय होता है। इस मामले में, ड्राइवर एक वेक लॉक पकड़ सकता है क्योंकि एपी के पास सस्पेंड मोड में प्रवेश करने का समय नहीं है, क्योंकि यह सस्पेंड मोड पर पहुंचने से पहले एक वेक-अप इवेंट द्वारा जगाया जाएगा।
वेक-अप सेंसर को बैचते समय बरती जाने वाली सावधानियां
डिवाइस के आधार पर, AP को सस्पेंड मोड से पूरी तरह बाहर आने और FIFO को फ्लश करना शुरू करने में कुछ मिलीसेकंड का समय लग सकता है। FIFO में पर्याप्त हेड रूम आवंटित किया जाना चाहिए ताकि डिवाइस को वेक-अप FIFO ओवरफ्लो किए बिना सस्पेंड मोड से बाहर आने की अनुमति मिल सके। कोई ईवेंट नहीं खोएगा, और max_report_latency
का सम्मान किया जाना चाहिए।
नॉन-वेक-अप ऑन-चेंज सेंसर को बैच करते समय बरती जाने वाली सावधानियां
ऑन-चेंज सेंसर केवल ईवेंट उत्पन्न करते हैं जब वे जिस मूल्य को माप रहे हैं वह बदल रहा है। यदि AP के सस्पेंड मोड में रहने के दौरान मापा गया मान बदल जाता है, तो AP के जागते ही एप्लिकेशन को एक ईवेंट प्राप्त होने की उम्मीद है। इस वजह से, गैर-वेक-अप ऑन-चेंज सेंसर ईवेंट की बैचिंग सावधानी से की जानी चाहिए यदि सेंसर अपने फीफो को अन्य सेंसर के साथ साझा करता है। प्रत्येक ऑन-चेंज सेंसर द्वारा उत्पन्न अंतिम घटना को हमेशा साझा फीफो के बाहर सहेजा जाना चाहिए ताकि इसे अन्य घटनाओं द्वारा कभी भी अधिलेखित नहीं किया जा सके। जब एपी जागता है, फीफो से सभी घटनाओं की सूचना मिलने के बाद, अंतिम ऑन-चेंज सेंसर घटना की सूचना दी जानी चाहिए।
यहाँ से बचने के लिए एक स्थिति है:
- एक आवेदन नॉन-वेक-अप स्टेप काउंटर (ऑन-चेंज) और नॉन-वेक-अप एक्सेलेरोमीटर (निरंतर) में पंजीकृत होता है, दोनों एक ही फीफो साझा करते हैं।
- एप्लिकेशन को एक चरण काउंटर ईवेंट प्राप्त होता है
step_count=1000 steps
code>. - एपी निलंबित करने के लिए चला जाता है।
- उपयोगकर्ता 20 कदम चलता है, जिससे चरण काउंटर और एक्सेलेरोमीटर ईवेंट इंटरलीव हो जाते हैं, अंतिम चरण काउंटर ईवेंट
step_count = 1020 steps
। - उपयोगकर्ता लंबे समय तक हिलता नहीं है, जिससे एक्सेलेरोमीटर ईवेंट FIFO में जमा होते रहते हैं, अंततः साझा FIFO में प्रत्येक
step_count
ईवेंट को ओवरराइट कर देते हैं। - एपी जागता है और फीफो से सभी घटनाओं को आवेदन पर भेजा जाता है।
- एप्लिकेशन केवल एक्सेलेरोमीटर ईवेंट प्राप्त करता है और सोचता है कि उपयोगकर्ता नहीं चला।
FIFO के बाहर अंतिम चरण काउंटर ईवेंट को सहेजकर, HAL इस घटना की रिपोर्ट कर सकता है जब AP जागता है, भले ही अन्य सभी चरण काउंटर ईवेंट एक्सेलेरोमीटर ईवेंट द्वारा अधिलेखित किए गए हों। इस तरह, एपी के जागने पर एप्लिकेशन को step_count = 1020 steps
प्राप्त होते हैं।
बैचिंग लागू करना
बिजली बचाने के लिए, एपी की सहायता के बिना बैचिंग को लागू किया जाना चाहिए, और एपी को बैचिंग के दौरान निलंबित करने की अनुमति दी जानी चाहिए।
यदि सेंसर हब में बैचिंग की जाती है, तो सेंसर हब की शक्ति का उपयोग कम से कम किया जाना चाहिए।
अधिकतम रिपोर्ट विलंबता को किसी भी समय संशोधित किया जा सकता है, विशेष रूप से जब निर्दिष्ट सेंसर पहले से ही सक्षम हो; और इसके परिणामस्वरूप घटनाओं का नुकसान नहीं होना चाहिए।
फीफो आवंटन प्राथमिकता
उन प्लेटफॉर्म पर जहां हार्डवेयर फीफो और/या सेंसर हब बफर आकार सीमित है, सिस्टम डिजाइनरों को यह चुनना पड़ सकता है कि प्रत्येक सेंसर के लिए कितना फीफो आरक्षित करना है। इस विकल्प में मदद करने के लिए, विभिन्न सेंसरों पर बैचिंग लागू करते समय संभावित अनुप्रयोगों की एक सूची यहां दी गई है।
उच्च मूल्य: कम शक्ति पैदल यात्री मृत गणना
लक्ष्य बैचिंग समय: 1 से 10 मिनट
बैच के लिए सेंसर:
- वेक-अप स्टेप डिटेक्टर
- 5 हर्ट्ज पर वेक-अप गेम रोटेशन वेक्टर
- 5 हर्ट्ज पर वेक-अप बैरोमीटर
- 5 हर्ट्ज पर बिना कैलिब्रेटेड मैग्नेटोमीटर को जगाना
इस डेटा को बैचने से एपी को निलंबित करने की अनुमति देते हुए पैदल यात्री मृत गणना करने की अनुमति मिलती है।
उच्च मूल्य: मध्यम शक्ति आंतरायिक गतिविधि / हावभाव पहचान
लक्ष्य बैचिंग समय: 3 सेकंड
बैच के लिए सेंसर: 50 हर्ट्ज पर नॉन-वेक-अप एक्सेलेरोमीटर
इस डेटा को बैचने से समय-समय पर मनमानी गतिविधियों और इशारों को पहचानने की अनुमति मिलती है, जबकि डेटा एकत्र किए जाने के दौरान एपी को जागृत रखने की आवश्यकता नहीं होती है।
मध्यम मूल्य: मध्यम शक्ति निरंतर गतिविधि/हावभाव पहचान
लक्ष्य बैचिंग समय: 1 से 3 मिनट
बैच के लिए सेंसर: 50 हर्ट्ज पर वेक-अप एक्सेलेरोमीटर
इस डेटा को बैचने से डेटा एकत्र होने के दौरान एपी को जगाए बिना मनमानी गतिविधियों और इशारों को लगातार पहचानने की अनुमति मिलती है।
मध्यम-उच्च मूल्य: लोड में कमी को बाधित करें
लक्ष्य बैचिंग समय: <1 सेकंड
बैच के लिए सेंसर: कोई भी उच्च-आवृत्ति सेंसर, आमतौर पर नॉन-वेक-अप।
यदि जाइरोस्कोप को 240 हर्ट्ज पर सेट किया जाता है, तो भी केवल 10 जाइरो इवेंट्स को बैचने से इंटरप्ट की संख्या 240/सेकंड से 24/सेकंड तक कम हो सकती है।
मध्यम मूल्य: निरंतर कम आवृत्ति डेटा संग्रह
लक्ष्य बैचिंग समय: 1 से 10 मिनट
बैच के लिए सेंसर:
- 1 हर्ट्ज . पर वेक-अप बैरोमीटर
- 1 हर्ट्ज पर वेक-अप ह्यूमिडिटी सेंसर
- अन्य कम आवृत्ति वाले वेक-अप सेंसर समान दरों पर
कम शक्ति पर निगरानी एप्लिकेशन बनाने की अनुमति देता है।
मध्यम-निम्न मान: निरंतर पूर्ण-सेंसर संग्रह
लक्ष्य बैचिंग समय: 1 से 10 मिनट
बैच के लिए सेंसर: सभी वेक-अप सेंसर, उच्च आवृत्तियों पर
AP को सस्पेंड मोड में छोड़ते समय सेंसर डेटा के पूर्ण संग्रह की अनुमति देता है। केवल तभी विचार करें जब फीफो स्पेस कोई समस्या नहीं है।