इस बारे में थोड़ा उलझन में। अगर मैं प्रोसेसर को तेज़ी से बढ़ाता हूं, तो क्या कोई काम करने में कम समय नहीं लगेगा और इसलिए समय सीमा जल्द ही ले जाएगी?रीयल टाइम सिस्टम में प्रोसेसर को तेज करने की वजह से मिस्ड टाइमलाइन क्यों होती है?
धन्यवाद
उत्तर यह है कि तेज गति के कारण नए संसाधन संघर्ष हो सकते हैं। इसे ग्राहम की विसंगति के रूप में जाना जाता है: यदि एक मल्टीप्रोसेसर पर एक कार्य सेट निर्धारित किया गया है, तो शेड्यूल की लंबाई कम हो जाती है, फिर प्रोसेसर बढ़ाना, निष्पादन के समय को कम करना, या कमजोर प्राथमिकता बाधाएं अनुसूची की लंबाई बढ़ा सकती हैं। उद्देश्य ध्यान दें (अनुसूची लंबाई को कम करें)। लेकिन विसंगतियों को आसानी से सच साबित किया जा सकता है यदि कार्यों की समयसीमा है और उद्देश्य सभी कार्य की समयसीमाओं को पूरा करना है। ऑपरेटिंग सिस्टम पर कई पुस्तकों में उदाहरणों के उदाहरणों के साथ यह अच्छी तरह से प्रलेखित है।
यह भी देखें:
हो सकता है कि - लेकिन कई प्रोसेसर तेजी लाने के लिए इस्तेमाल तकनीक (जैसे, संचय करना) भी उन्हें कम पूर्वानुमान बनाते हैं। इनमें से अधिकतर तकनीक औसत केस (अक्सर काफी खराब) के सबसे खराब मामले की कीमत पर सुधार करती हैं - उदाहरण के लिए, एक कैश के साथ, सबसे खराब स्थिति में स्मृति से एक कैश बिना कैश के धीमा हो सकता है क्योंकि इसके अतिरिक्त स्मृति से लाने का समय, कुछ कैश को खोजने के लिए समय निकाला गया है यह देखने के लिए कि डेटा मौजूद है या नहीं।
दुर्भाग्य से, वास्तविक समय निर्धारण के लिए, आपकी चिंता मुख्य रूप से सबसे खराब मामला है, नहीं औसत मामले के साथ है, इसलिए भले ही इस तरह के एक अनुकूलन सबसे कोड तेजी से समय की सबसे बनाता है, यह अभी भी एक लापता का कारण बन सकता एक वास्तविक समय प्रणाली में समय सीमा।
इसके अलावा, यदि सीपीयू और बाकी सिस्टम के बीच कोई संसाधन साझा किया गया है और संसाधन विवाद सीपीयू की गति के साथ बढ़ता है और एक बाधा बन जाता है (शायद संसाधन भुखमरी के साथ), उस समय की समय सीमा समाप्त हो सकती है। –
निर्भर करता है ... प्रोसेसर को तेज करने से सिस्टम के अन्य हिस्सों (मेमोरी एक्सेस टाइम्स, प्रोपेगेशन विलंब इत्यादि) पर असर नहीं पड़ता है। प्रोसेसर की गति में वृद्धि से ये चीजें कार्य के लिए प्रसंस्करण समय का एक बड़ा हिस्सा लेती हैं।
यदि प्रोसेसर की गति में वृद्धि हुई है, तो प्रचार प्रणाली एक घड़ी चक्र से अधिक हो सकती है, संभवतया पुन: प्रयास करने के कारण देरी हो सकती है, इस पर निर्भर करता है कि आपका सिस्टम कैसा स्थापित है।
यदि प्रोसेसर के आधार पर काउंटर या टाइमर से समय सीमा तय की जाती है, तो यह आनुपातिक रूप से अधिक मात्रा में भी बढ़ेगा, क्योंकि काउंटर के लिए मुख्य मेमोरी एक्सेस नहीं है।
इनमें से कोई भी संभवतः आपके विशेष सेटअप के आधार पर कारकों में से एक हो सकता है।
इस तरह की चीजें होती हैं, और डगलस ने पहले ही ग्राहम विसंगति को समझाया है। मैं इसे थोड़ा उदाहरण के साथ समझाऊंगा। मुझे आशा है कि यह समझना आसान हो जाएगा कि क्या हो रहा है:
विसंगति उत्पन्न होती है यदि आप एकाधिक समवर्ती कार्यों और निश्चित गति के साझा संसाधन जैसे संचार चैनल के साथ काम कर रहे हैं।
वास्तविक समय प्रणाली के संदर्भ में इसके लिए एक अच्छा उदाहरण डेटा अधिग्रहण है।यदि आपको एनालॉग-टू-डिजिटल कनवर्टर से डेटा के एक्स मिलीसेकंड को पढ़ना है, तो यह हमेशा CPU मिली के बावजूद एक्स मिलीसेकंड लेगा। मेरे उदाहरण में मैं इसे 'आईओ-टाइम' या 'आईओ-टास्क' कहता हूं।
अब इस परिदृश्य पर विचार:
आप एक काम (ए) के होते हैं जो है
एक दूसरा कार्य (बी) एक हार्डवेयर घटना द्वारा शुरू किया जाएगा:
दूसरा कार्य मिलीसेकंड 3.
आईओ और सीपीयू पर शुरू कर दिया जाता है साझा संसाधन कर रहे हैं। वे समानांतर में चल सकते हैं, लेकिन या तो आईओ या सीपीयू एक समय में केवल एक ही काम को संसाधित कर सकता है।
एक इस के लिए संभव अनुसूची ऐसा दिखाई दे सकता:
timestamp: cpu/io job:
---------------------------------------------
t=0 event <--- hardware event triggers task-a
t=0 cpu start of task-a (4 ms)
t=3 event <--- hardware event triggers task-b
t=3 io start of task-b (4 ms)
t=4 cpu task-a done
t=7 io task-b done
t=7 io start of task-a (4 ms)
t=7 cpu start of task-b (2 ms)
t=9 cpu task-b done
t=10 io task-a done
अब हम CPU शक्ति दोगुनी है, ताकि cpu दोगुनी गति से चलेंगे:
timestamp: cpu/io job:
---------------------------------------------
t=0 event <--- hardware event triggers task-a
t=0 cpu start of task-a (2 ms)
t=2 cpu task a done
t=2 io start of task a (4 ms)
t=3 event <--- hardware event triggers task-b, but can't start
because io-bus is busy. Must wait.
t=6 io task a done
t=6 io start of task b (4 ms)
t=10 io task b done
t=10 cpu start of task b (1 ms)
t=11 cpu task b done
आप देख सकते हैं, सीपीयू की गति में सुधार ने धीरे-धीरे सीपीयू परिदृश्य की तुलना में दो कार्यों को एक मिलीसेकंड खत्म करने का कारण बना दिया। ऐसा इसलिए है क्योंकि हार्डवेयर घटना होने पर निश्चित गति साझा संसाधन व्यस्त था।
यह केवल एक मिलीसेकंद है, लेकिन ये चीजें जोड़ सकती हैं और मिस्ड समय सीमाएं पैदा कर सकती हैं।
आपको क्या लगता है कि यह सच है? क्या यह एक समस्या है जिसे आपने अनुभव किया है, या कुछ जो आपको बताया गया है या पढ़ा गया है? उद्धरण आवश्यक है। – Clifford