क्या कोई वास्तव में समझ सकता है कि लिनक्स / बीएसडी में HFSC शेड्यूल कैसे करता है?


35

मैंने HFSC के बारे में मूल SIGCOMM '97 पोस्टस्क्रिप्ट पेपर पढ़ा, यह बहुत तकनीकी रूप से है, लेकिन मैं मूल अवधारणा को समझता हूं। एक रैखिक सेवा वक्र देने के बजाय (जैसा कि हर दूसरे शेड्यूलिंग एल्गोरिदम के साथ), आप उत्तल या अवतल सेवा वक्र निर्दिष्ट कर सकते हैं और इस प्रकार बैंडविड्थ और देरी को कम करना संभव है। हालाँकि, भले ही इस पेपर में शेड्यूलिंग एल्गोरिदम का उपयोग करने (वास्तविक समय और लिंक-शेयर) के लिए उल्लेख किया गया है, यह हमेशा केवल शेड्यूलिंग क्लास के एक वक्र का उल्लेख करता है (डिकॉउलिंग इस वक्र को निर्दिष्ट करके किया जाता है, केवल एक वक्र की आवश्यकता है )।

अब एचएफएससी को बीएसडी (ओपनबीएसडी, फ्रीबीएसडी, आदि) के लिए एएलटीक्यू शेड्यूलिंग फ्रेमवर्क का उपयोग करके लागू किया गया है और इसे टीसी शेड्यूलिंग फ्रेमवर्क (आईप्रूटे 2 के हिस्से) का उपयोग करके लिनक्स को लागू किया गया है । दोनों कार्यान्वयन में दो अतिरिक्त सेवा वक्र शामिल थे, जो मूल पेपर में नहीं थे ! एक वास्तविक समय सेवा वक्र और एक ऊपरी-सीमा सेवा वक्र। फिर, कृपया ध्यान दें कि मूल पेपर में दो शेड्यूलिंग एल्गोरिदम (वास्तविक समय और लिंक-शेयर) का उल्लेख है, लेकिन उस पेपर में दोनों एक ही सेवा वक्र के साथ काम करते हैं। बीएसडी और लिनक्स में वर्तमान में आपको कभी भी एक के लिए दो स्वतंत्र सेवा वक्र नहीं मिले हैं।

इससे भी बदतर, एएलटीक्यू के कुछ संस्करण एचएसएफसी के लिए एक अतिरिक्त कतार प्राथमिकता जोड़ना चाहते हैं (मूल पेपर में प्राथमिकता जैसी कोई चीज नहीं है)। मैंने पाया कि कई BSD HowTo ने इस प्राथमिकता सेटिंग का उल्लेख किया है (भले ही नवीनतम ALTQ रिलीज़ का मैन पेज HSFC के लिए ऐसा कोई पैरामीटर नहीं जानता है, इसलिए आधिकारिक तौर पर यह मौजूद भी नहीं है)।

यह सब मूल पेपर में वर्णित एल्गोरिदम की तुलना में एचएफएससी को और भी अधिक जटिल बनाता है और इंटरनेट पर बहुत सारे ट्यूटोरियल हैं जो अक्सर एक दूसरे के विपरीत होते हैं, एक दूसरे के विपरीत का दावा करता है। यह शायद मुख्य कारण है कि कोई भी वास्तव में यह नहीं समझता है कि एचएफएससी वास्तव में कैसे काम करता है। इससे पहले कि मैं अपने प्रश्न पूछूं, हमें किसी प्रकार के एक नमूना सेटअप की आवश्यकता है। मैं एक बहुत ही सरल का उपयोग करूँगा जैसा कि नीचे की छवि में देखा गया है:

alt text http://f.imagehost.org/0177/hfsc-test-setup.png

यहाँ कुछ प्रश्न दिए गए हैं जिनका मैं जवाब नहीं दे सकता क्योंकि ट्यूटोरियल एक दूसरे के विपरीत हैं:

  1. मुझे एक वास्तविक समय वक्र की क्या आवश्यकता है? मान लें कि A1, A2, B1, B2 सभी 128 kbit / s लिंक-शेयर (किसी एक के लिए कोई वास्तविक समय वक्र नहीं है), तो उन सभी को 128 kbit / s मिलेगा यदि रूट को वितरित करने के लिए 512 kbit / s है (और A और B दोनों 256 kbit / s पाठ्यक्रम के हैं), है ना? मैं अतिरिक्त रूप से A1 और B1 को 128 kbit / s के साथ एक वास्तविक समय वक्र क्यों दूंगा? इसके लिए क्या अच्छा होगा? उन दो को उच्च प्राथमिकता देने के लिए? मूल कागज के अनुसार मैं एक वक्र का उपयोग करके उन्हें एक उच्च प्राथमिकता दे सकता हूं , यही एचएफएससी आखिरकार क्या है। दोनों वर्गों को [256kbit / s 20ms 128kbit / s] का वक्र प्रदान करने से, दोनों A2 और B2 की तुलना में दो बार स्वचालित रूप से प्राथमिकता देते हैं (अभी भी औसतन केवल 128 kbit / s प्राप्त कर रहे हैं)

  2. क्या वास्तविक समय बैंडविड्थ लिंक-शेयर बैंडविड्थ की ओर गिनती करता है? जैसे अगर A1 और B1 दोनों में केवल 64kbit / s का वास्तविक समय और 64kbit / s का लिंक शेयर बैंडविड्थ है, तो इसका मतलब यह है कि एक बार जब वे वास्तविक समय के माध्यम से 64kbit / s सेवा कर रहे हैं, तो उनकी लिंक-शेयर आवश्यकता भी संतुष्ट है (वे हो सकते हैं) अतिरिक्त बैंडविड्थ प्राप्त करें, लेकिन इसे एक सेकंड के लिए अनदेखा करें) या इसका मतलब है कि उन्हें लिंक-शेयर के माध्यम से एक और 64 kbit / s मिलता है? तो क्या प्रत्येक वर्ग के पास रियल-टाइम प्लस लिंक-शेयर की बैंडविड्थ "आवश्यकता" है? या क्या किसी वर्ग को केवल वास्तविक समय के वक्र की तुलना में अधिक आवश्यकता होती है, यदि लिंक-शेयर वक्र वास्तविक समय वक्र की तुलना में अधिक है (वर्तमान लिंक-शेयर आवश्यकता निर्दिष्ट लिंक-शेयर आवश्यकता के बराबर है, जो पहले से ही प्रदान की गई वास्तविक समय बैंडविड्थ है कक्षा)?

  3. क्या ऊपरी सीमा वक्र वास्तविक समय के लिए भी लागू है, केवल लिंक-शेयर या शायद दोनों के लिए? कुछ ट्यूटोरियल एक तरह से कहते हैं, कुछ दूसरे तरीके से कहते हैं। कुछ भी दावा करते हैं कि ऊपरी-सीमा वास्तविक-समय बैंडविड्थ + लिंक-शेयर बैंडविड्थ के लिए अधिकतम है? सच क्या है?

  4. A2 और B2 को मानें तो 128 kbit / s हैं, क्या इससे कोई फर्क पड़ता है अगर A1 और B1 केवल 128 kbit / s लिंक-शेयर हैं, या 64 kbit / s वास्तविक-समय और 128 kbit / s-share-share, और यदि हैं , क्या अंतर है?

  5. अगर मैं कक्षाओं की प्राथमिकताओं को बढ़ाने के लिए अलग-अलग वास्तविक समय वक्र का उपयोग करता हूं, तो मुझे "वक्र" की आवश्यकता क्यों होगी? रियल-टाइम एक फ्लैट मूल्य और लिंक-शेयर भी एक फ्लैट मूल्य क्यों नहीं है? दोनों वक्र क्यों हैं? मूल कागज में घटता की आवश्यकता स्पष्ट है, क्योंकि प्रति वर्ग उस तरह का एक ही गुण है। लेकिन अब, तीन विशेषताएँ (वास्तविक समय, लिंक-शेयर, और ऊपरी-सीमा) होने के लिए मुझे अभी भी प्रत्येक पर घटता की क्या आवश्यकता है? मैं वास्तविक समय और लिंक-साझा ट्रैफ़िक के लिए घटता आकार (औसत बैंडविड्थ नहीं, बल्कि उनकी ढलान) क्यों चाहूंगा ?

  6. उपलब्ध छोटे दस्तावेज़ों के अनुसार, वास्तविक समय वक्र मानों को आंतरिक कक्षाओं (कक्षा ए और बी) के लिए पूरी तरह से अनदेखा किया जाता है, वे केवल लीफ क्लास (ए 1, ए 2, बी 1, बी 2) पर लागू होते हैं। यदि यह सच है, तो ALTQ HFSC नमूना कॉन्फ़िगरेशन ( 3.3 नमूना कॉन्फ़िगरेशन के लिए खोज ) आंतरिक कक्षाओं पर वास्तविक समय घटता क्यों सेट करता है और दावा करता है कि उन आंतरिक वर्गों की गारंटीकृत दर निर्धारित करता है? क्या यह पूरी तरह से व्यर्थ नहीं है? (नोट: pshare ALTQ में लिंक-शेयर वक्र सेट करता है और वास्तविक समय वक्र को grate करता है; आप इसे नमूना कॉन्फ़िगरेशन के ऊपर पैराग्राफ में देख सकते हैं)।

  7. कुछ ट्यूटोरियल कहते हैं कि सभी वास्तविक समय घटता का योग लाइन गति के 80% से अधिक नहीं हो सकता है, दूसरों का कहना है कि यह लाइन की गति के 70% से अधिक नहीं होना चाहिए। कौन सा सही है या वे दोनों गलत हैं?

  8. एक ट्यूटोरियल ने कहा कि आप सभी सिद्धांत भूल जाएंगे। कोई फर्क नहीं पड़ता कि चीजें वास्तव में कैसे काम करती हैं (शेड्यूलर्स और बैंडविड्थ वितरण), निम्नलिखित "सरलीकृत माइंड मॉडल" के अनुसार तीन घटों की कल्पना करें: वास्तविक समय की गारंटी बैंडविड्थ है जो इस वर्ग को हमेशा मिलेगी। लिंक-शेयर वह बैंडविड्थ है जो यह वर्ग पूरी तरह से संतुष्ट होना चाहता है, लेकिन संतुष्टि की गारंटी नहीं दी जा सकती है। यदि अतिरिक्त बैंडविड्थ है, तो कक्षा को संतुष्ट होने के लिए आवश्यक से अधिक बैंडविड्थ की पेशकश भी मिल सकती है, लेकिन यह कभी भी ऊपरी सीमा से अधिक का उपयोग नहीं कर सकता है। यह सब काम करने के लिए, सभी वास्तविक समय के बैंडविंड का योग लाइन गति के xx% से ऊपर नहीं हो सकता है (ऊपर प्रश्न देखें, प्रतिशत भिन्न होता है)। प्रश्न: क्या यह कमोबेश सटीक है या HSFC की कुल गलतफहमी है?

  9. और अगर ऊपर की धारणा वास्तव में सटीक है, तो उस मॉडल में प्राथमिकता कहां है? उदाहरण के लिए हर वर्ग में एक वास्तविक समय बैंडविड्थ (गारंटीकृत), एक लिंक-शेयर बैंडविड्थ (गारंटी नहीं) और एक ऊपरी सीमा हो सकती है, लेकिन फिर भी कुछ वर्गों में अन्य वर्गों की तुलना में उच्च प्राथमिकता की आवश्यकता होती है। उस स्थिति में मुझे अभी भी किसी तरह प्राथमिकता देनी चाहिए, यहां तक ​​कि उन कक्षाओं के वास्तविक समय के यातायात के बीच भी। क्या मैं घटता के ढलान से प्राथमिकता दूंगा? और यदि हां, तो कौन सा वक्र? वास्तविक समय वक्र? लिंक-शेयर वक्र? ऊपरी सीमा वक्र? उन सभी को? क्या मैं उन सभी को एक ही ढलान या एक अलग एक दे दूंगा और सही ढलान का पता कैसे लगाऊंगा?

मैंने अभी भी उम्मीद नहीं खोई है कि इस दुनिया में कम से कम ऐसे लोगों से भरा हुआ है जो वास्तव में एचएफएससी को समझते हैं और सभी सवालों के सही जवाब देने में सक्षम हैं। और जवाब में एक दूसरे का विरोध किए बिना ऐसा करना वास्तव में अच्छा होगा ;-)


पलक झपकना
मैट सिमंस

5
सौभाग्य। शायद आपको सॉफ्टवेयर के लेखक को लिखना चाहिए और उनसे इसके बारे में बात करनी चाहिए। मुझे यकीन है कि वे अपने विषय में रुचि रखने वाले किसी अन्य व्यक्ति से सुनना पसंद करेंगे।
मैट सिमंस

1
IMHO यह प्रश्न बहुत अधिक अकादमिक है और यहाँ व्यावहारिक उत्तर प्राप्त करने के लिए बहुत उपयुक्त नहीं है। मैं मैट से सहमत हूं कि लेखक या लेखकों के साथ कुछ संवाद आपकी सबसे अच्छी कार्रवाई है।
जोकेवेटी

2
आप कागज के लेखक को एक ईमेल भेज सकते हैं? शायद वह कोड के माध्यम से उतारा करने में मदद कर सके?
मैट सिमंस

4
+1 मैट। मैकी, मुझे संदेह है कि आपके प्रश्न का शाब्दिक उत्तर "नहीं" है।
रिचर्ड होलोवे

जवाबों:


16

एचएफएससी और उसके चचेरे भाइयों पर कागजात पढ़ना, इसे समझने का एक अच्छा तरीका नहीं है। HFSC पेपर का प्राथमिक लक्ष्य अपने दावों का एक कठोर गणितीय प्रमाण प्रदान करना है, न कि यह बताना कि यह कैसे काम करता है। वास्तव में आप यह नहीं समझ सकते हैं कि यह अकेले HFSC पेपर से कैसे काम करता है, आपको इसके संदर्भ में भी कागजात पढ़ना होगा। यदि आपको दावे या उनके प्रमाणों से कुछ समस्या है, तो कागजात के लेखकों से संपर्क करना एक अच्छा विचार हो सकता है, अन्यथा मुझे संदेह है कि वे आपसे सुनने में रुचि लेंगे।

मैंने HFSC के लिए एक ट्यूटोरियल लिखा है । यदि मेरा स्पष्टीकरण स्पष्ट नहीं है तो इसे पढ़ें।

मुझे एक वास्तविक समय वक्र की क्या आवश्यकता है? मान लें कि A1, A2, B1, B2 सभी 128 kbit / s लिंक-शेयर (किसी एक के लिए कोई वास्तविक समय वक्र नहीं है), तो उन सभी को 128 kbit / s मिलेगा यदि रूट को वितरित करने के लिए 512 kbit / s है (और A और B दोनों 256 kbit / s पाठ्यक्रम के हैं), है ना? मैं अतिरिक्त रूप से A1 और B1 को 128 kbit / s के साथ एक वास्तविक समय वक्र क्यों दूंगा? इसके लिए क्या अच्छा होगा? उन दो को उच्च प्राथमिकता देने के लिए? मूल कागज के अनुसार मैं एक वक्र का उपयोग करके उन्हें एक उच्च प्राथमिकता दे सकता हूं, यही एचएफएससी आखिरकार क्या है। दोनों वर्गों को [256kbit / s 20ms 128kbit / s] का वक्र प्रदान करने से, दोनों A2 और B2 की तुलना में दो बार स्वचालित रूप से प्राथमिकता देते हैं (अभी भी औसतन केवल 128 kbit / s प्राप्त कर रहे हैं)

वास्तविक समय वक्र और लिंक साझाकरण वक्र का मूल्यांकन अलग-अलग तरीकों से किया जाता है। वास्तविक समय वक्र को ध्यान में रखता है कि एक वर्ग ने पूरे इतिहास में क्या किया है। यह सटीक बैंडविड्थ और विलंबता आवंटन प्रदान करने के लिए करना चाहिए। नकारात्मक पक्ष यह नहीं है कि ज्यादातर लोग सहज रूप से उचित के बारे में क्या सोचते हैं । वास्तविक समय के तहत, यदि कोई वर्ग बैंडविड्थ को उधार लेता है जब कोई और नहीं चाहता है, तो उसे दंडित किया जाता है जब कोई और इसे बाद में वापस चाहता है। इसका मतलब यह है कि वास्तविक समय की गारंटी के तहत एक वर्ग को लंबी अवधि के लिए कोई बैंडविड्थ नहीं मिल सकता है क्योंकि यह पहले इस्तेमाल करता था, जब कोई भी इसे नहीं चाहता था।

लिंक साझा करना उचित है, इसमें यह अतिरिक्त बैंडविड्थ का उपयोग करने के लिए एक वर्ग को दंडित नहीं करता है। हालांकि इसका मतलब है कि यह मजबूत विलंबता गारंटी प्रदान नहीं कर सकता है।

लेटेंसी गारंटी प्रदान करने से लिंक साझाकरण को अलग करना HFSC तालिका में लाता है नई बात है, और पेपर कहता है कि यह शुरुआती वाक्य है: इस पेपर में, हम पदानुक्रमित संसाधन प्रबंधन मॉडल और एल्गोरिदम का अध्ययन करते हैं जो लिंक-शेयरिंग और गारंटी दोनों का समर्थन करते हैं विघटित विलंब (प्राथमिकता) और बैंडविड्थ आवंटन के साथ वास्तविक समय सेवाएं। उस वाक्य में मुख्य शब्द डिकोड किया गया है। अनुवादित, इसका मतलब है कि आपसे यह अपेक्षा की जाती है कि अप्रयुक्त बैंडविड्थ को ls के साथ कैसे साझा किया जाए, और यह निर्दिष्ट करें कि rt के साथ वास्तविक समय की गारंटी (उर्फ विलंबता गारंटी) की क्या आवश्यकता है। दो ऑर्थोगोनल हैं।

क्या वास्तविक समय बैंडविड्थ लिंक-शेयर बैंडविड्थ की ओर गिनती करता है?

हाँ। एचएफएससी पेपर में वे बैंडविड्थ को परिभाषित करते हैं कि क्लास ने क्या भेजा है क्योंकि क्लास बैकलॉग हो गया है (यानी पैकेट भेजे जाने की प्रतीक्षा कर रहा है)। आरटी और एलएस के बीच एकमात्र अंतर यह है कि आरटी हर बार टाइम क्लास से बैकलॉग हो जाता है और उस सेट से सबसे कम गारंटीड बैंडविड्थ की गणना करता है, जबकि लिंक शेयरिंग केवल पिछली बार से दिखता है क्योंकि क्लास बैकलॉग हो गया है। इसलिए rt, ls की तुलना में अधिक बाइट्स को ध्यान में रखता है, लेकिन प्रत्येक बाइट ls को rt द्वारा भी माना जाता है।

क्या ऊपरी सीमा वक्र वास्तविक समय के लिए भी लागू है, केवल लिंक-शेयर या शायद दोनों के लिए?

ऊपरी सीमा पैकेट को वास्तविक समय की स्थिति को संतुष्ट करने के लिए भेजे जाने से नहीं रोकती है। वास्तविक समय स्थिति के तहत भेजे गए पैकेट अभी भी ऊपरी सीमा की ओर ही हैं, और इस प्रकार भविष्य में लिंक साझा करने की स्थिति के तहत भेजे जाने वाले पैकेट में देरी हो सकती है। यह वास्तविक समय और लिंक शेयर के बीच एक और अंतर है।

A2 और B2 को मानें तो 128 kbit / s हैं, क्या इससे कोई फर्क पड़ता है अगर A1 और B1 केवल 128 kbit / s लिंक-शेयर हैं, या 64 kbit / s वास्तविक-समय और 128 kbit / s-share-share, और यदि हैं , क्या अंतर है?

हां, इससे फर्क पड़ता है। जैसा कि ऊपर बताया गया है कि यदि आप वास्तविक समय का उपयोग करते हैं, तो विलंबता की गारंटी होती है लेकिन लिंक को निष्पक्ष रूप से साझा नहीं किया जाता है (और विशेष रूप से वर्ग बैंडविड्थ भुखमरी का सामना कर सकता है), और ऊपरी सीमाएं लागू नहीं होती हैं। यदि आप लिंक का उपयोग करते हैं तो शेयर विलंबता की गारंटी नहीं है, लेकिन लिंक साझा करना उचित है, भुखमरी का कोई खतरा नहीं है, और ऊपरी सीमा लागू है। लिंक साझा करने से पहले वास्तविक समय की हमेशा जांच की जाती है, हालांकि यह आवश्यक नहीं है कि लिंक शेयर को नजरअंदाज कर दिया जाएगा। ऐसा इसलिए क्योंकि पैकेट की गिनती अलग तरह से की जाती है। चूँकि इतिहास को वास्तविक समय माना जाता है इसलिए एक पैकेट को वास्तविक समय की गारंटी (क्योंकि इतिहास से गिना जाता है) को पूरा करने की आवश्यकता नहीं है, लेकिन लिंक शेयर को संतुष्ट करने के लिए आवश्यक है क्योंकि यह ऐतिहासिक पैकेट की उपेक्षा करता है।

अगर मैं कक्षाओं की प्राथमिकताओं को बढ़ाने के लिए अलग-अलग वास्तविक समय वक्र का उपयोग करता हूं, तो मुझे "वक्र" की आवश्यकता क्यों होगी? रियल-टाइम एक फ्लैट मूल्य और लिंक-शेयर भी एक फ्लैट मूल्य क्यों नहीं है? दोनों वक्र क्यों हैं? मूल पेपर में कर्व्स की आवश्यकता स्पष्ट है, क्योंकि प्रति वर्ग उस तरह का एक ही गुण है। लेकिन अब, तीन विशेषताएँ (वास्तविक समय, लिंक-शेयर, और ऊपरी-सीमा) होने के लिए मुझे अभी भी प्रत्येक पर घटता की क्या आवश्यकता है? मैं वास्तविक समय और लिंक-साझा ट्रैफ़िक के लिए घटता आकार (औसत बैंडविड्थ नहीं, बल्कि उनकी ढलान) क्यों चाहूंगा?

वास्तविक समय नियंत्रण के लिए वक्र आपको अन्य ट्रैफ़िक वर्गों (जैसे ईमेल) के लिए खराब विलंबता के लिए एक विशेष ट्रैफ़िक वर्ग (जैसे वीओआईपी) के लिए तंग विलंबता का व्यापार करने की अनुमति देता है। वास्तविक समय की कमी के तहत कौन सा पैकेट भेजना है, यह तय करते समय एचएफएससी वह चुनता है जो पहले भेजना पूरा करेगा। हालांकि, यह गणना करने के लिए लिंक की बैंडविड्थ का उपयोग नहीं करता है, यह वास्तविक समय वक्र द्वारा आवंटित बैंडविड्थ का उपयोग करता है। इस प्रकार यदि हमारे पास वीओआइपी और एक ही लंबाई के ईमेल पैकेट हैं, और वीओआइपी पैकेट में एक उत्तल वक्र है, जो यह बताता है कि यदि ईमेल के लिए अवतल वक्र पर 10 गुना वृद्धि होती है, तो मुट्ठी वाले ईमेल पैकेट से पहले 10 वीओआइपी पैकेट भेजे जाएंगे। लेकिन यह केवल फटने के समय के लिए होता है, जो कि कुछ पैकेटों को भेजने में अधिक से अधिक समय होना चाहिए - यानी मिली सेकंड। इसके बाद वीओआइपी वक्र को समतल करना चाहिए, और वीओआइपी को भविष्य में तब तक बढ़ावा नहीं मिलेगा जब तक कि यह थोड़ी देर के लिए बंद नहीं हो जाता (जो, वीओआइपी एक कम बैंडविड्थ अनुप्रयोग है, इसे करना चाहिए)। इस सब का शुद्ध परिणाम यह सुनिश्चित करना है कि वीओआइपी पैकेटों के पहले जोड़े को किसी भी चीज़ की तुलना में तेजी से भेजा जाए, इस प्रकार उच्च विलंबता प्राप्त करने वाले ईमेल की कीमत पर वीओआइपी कम विलंबता देता है।

जैसा कि मैंने पहले कहा था, क्योंकि लिंक शेयर इतिहास को नहीं देखता है, यह विलंबता की गारंटी नहीं दे सकता है। एक ठोस ठोस गारंटी जो वीओआइपी की तरह वास्तविक समय यातायात के लिए आवश्यक है। हालांकि, औसतन एक लिंक साझा उत्तल वक्र अभी भी अपने ट्रैफ़िक को विलंबता को बढ़ावा देगा। इसकी गारंटी नहीं है। यह ज्यादातर चीजों के लिए ठीक है, जैसे ईमेल पर वेब ट्रैफिक।

उपलब्ध छोटे दस्तावेज़ों के अनुसार, वास्तविक समय वक्र मानों को आंतरिक कक्षाओं (कक्षा ए और बी) के लिए पूरी तरह से अनदेखा किया जाता है, वे केवल लीफ क्लास (ए 1, ए 2, बी 1, बी 2) पर लागू होते हैं। यदि यह सच है, तो ALTQ HFSC नमूना कॉन्फ़िगरेशन (3.3 नमूना कॉन्फ़िगरेशन के लिए खोज) आंतरिक कक्षाओं पर वास्तविक समय घटता क्यों सेट करता है और दावा करता है कि उन आंतरिक वर्गों की गारंटीकृत दर निर्धारित करता है? क्या यह पूरी तरह से व्यर्थ नहीं है? (नोट: pshare ALTQ में लिंक-शेयर वक्र सेट करता है और वास्तविक समय वक्र को grate करता है; आप इसे नमूना कॉन्फ़िगरेशन के ऊपर पैराग्राफ में देख सकते हैं)।

दस्तावेज सही है। पदानुक्रम (और इस प्रकार आंतरिक नोड्स) का वास्तविक समय की गणना पर कोई प्रभाव नहीं पड़ता है। मैं आपको यह नहीं बता सकता कि ALTQ स्पष्ट रूप से यह क्यों सोचता है।

कुछ ट्यूटोरियल कहते हैं कि सभी वास्तविक समय घटता का योग लाइन गति के 80% से अधिक नहीं हो सकता है, दूसरों का कहना है कि यह लाइन की गति के 70% से अधिक नहीं होना चाहिए। कौन सा सही है या वे दोनों गलत हैं?

दोनों गलत हैं। यदि आपके ट्रैफ़िक की 70% या 80% आवश्यकताओं में विलंबता की आवश्यकता है, जिसे वास्तविक समय के साथ निर्दिष्ट किया जाना चाहिए, तो वास्तविकता यह है कि आप निश्चित रूप से उन लिंक से संतुष्ट नहीं हो सकते जो आप उपयोग कर रहे हैं। आपको एक तेज़ लिंक की आवश्यकता है।

एकमात्र तरीका जो कोई सोच सकता था कि 80% ट्रैफ़िक निर्दिष्ट करने का वास्तविक समय होना चाहिए, यदि वे वास्तविक समय को प्राथमिकता के रूप में बढ़ावा दे रहे थे। हां, कुछ पैकेटों की प्राथमिकता को बढ़ावा देने के लिए आप विलंबता की गारंटी प्रदान करते हैं। लेकिन यह केवल मिलीसेकंड के लिए होना चाहिए। यह सब एक कड़ी के साथ सामना कर सकता है और अभी भी विलंबता की गारंटी प्रदान कर सकता है।

वहाँ बहुत कम यातायात है कि विलंबता गारंटी की आवश्यकता है। वीओआइपी एक है, एनटीपी एक और। बाकी सब लिंक शेयरिंग के साथ किया जाना चाहिए। यह आप चाहते हैं कि वेब तेज़ हो, आप इसे अधिकांश लिंक क्षमता को आवंटित करके तेज़ बनाते हैं। लंबी अवधि में उस शेयर की गारंटी होती है। यह आप चाहते हैं कि यह कम विलंबता (औसत पर) हो, इसे लिंक साझा करने के तहत उत्तल वक्र दें।

एक ट्यूटोरियल ने कहा कि आप सभी सिद्धांत भूल जाएंगे। कोई फर्क नहीं पड़ता कि चीजें वास्तव में कैसे काम करती हैं (शेड्यूलर्स और बैंडविड्थ वितरण), निम्नलिखित "सरलीकृत माइंड मॉडल" के अनुसार तीन घटों की कल्पना करें: वास्तविक समय की गारंटी बैंडविड्थ है जो इस वर्ग को हमेशा मिलेगी। लिंक-शेयर वह बैंडविड्थ है जो यह वर्ग पूरी तरह से संतुष्ट होना चाहता है, लेकिन संतुष्टि की गारंटी नहीं दी जा सकती है। यदि अतिरिक्त बैंडविड्थ है, तो कक्षा को संतुष्ट होने के लिए आवश्यक से अधिक बैंडविड्थ की पेशकश भी मिल सकती है, लेकिन यह कभी भी ऊपरी सीमा से अधिक का उपयोग नहीं कर सकता है। यह सब काम करने के लिए, सभी वास्तविक समय के बैंडविंड का योग लाइन गति के xx% से ऊपर नहीं हो सकता है (ऊपर प्रश्न देखें, प्रतिशत भिन्न होता है)। प्रश्न: क्या यह कमोबेश सटीक है या HSFC की कुल गलतफहमी है?

यह एक अच्छा वर्णन ऊपरी सीमा है। जबकि लिंक शेयर विवरण कड़ाई से सटीक है, यह भ्रामक है। हालांकि यह सही लिंक शेयर है वास्तविक समय जैसी कठिन विलंबता की गारंटी नहीं देता है, यह वर्ग को अपने प्रतिस्पर्धियों की तुलना में अपने आवंटन को सीबीक्यू और एचटीबी की तरह देने का बेहतर काम करता है। इसलिए लिंक शेयर में "गारंटी प्रदान नहीं करता है" यह इसे एक मानक उच्च स्तर पर पकड़ रहा है जो कोई अन्य अनुसूचक प्रदान कर सकता है।

वास्तविक समय का वर्णन दोनों सटीक है, लेकिन इतना भ्रामक है कि मैं इसे गलत कहूंगा। जैसा कि नाम से प्रतीत होता है कि वास्तविक समय का उद्देश्य गारंटीकृत बैंडविड्थ देना नहीं है। यह गारंटीकृत विलंबता प्रदान करना है - यानी पैकेट अब भेजा जाता है, लिंक के उपयोग के तरीके के आधार पर बाद में कुछ यादृच्छिक राशि नहीं। अधिकांश ट्रैफ़िक को गारंटी विलंबता की आवश्यकता नहीं है।

कहा कि, वास्तविक समय या तो सही विलंबता गारंटी नहीं देता है। यदि लिंक लिंक शेयर के द्वारा भी प्रबंधित नहीं किया जा सकता है, लेकिन अधिकांश उपयोगकर्ता दोनों के होने का अतिरिक्त लचीलापन चाहते हैं और यह मुफ्त में नहीं आता है। वास्तविक समय यह याद कर सकता है कि एक एमटीयू पैकेट भेजने में लगने वाली समय सीमा तक यह समय सीमा समाप्त हो जाएगी। (यदि ऐसा होता है, तो ऐसा इसलिए होगा क्योंकि यह एमटीयू पैकेट लिंक शेयर स्नैक था, जबकि वास्तविक समय में लिंक को निष्क्रिय रखने के लिए इसे एक छोटी समय सीमा के साथ पैकेट दिया गया था जिसे तुरंत भेजा जाना था। यह लिंक के बीच एक और अंतर है। और वास्तविक समय। इसकी गारंटी प्रदान करने के लिए वास्तविक समय जानबूझकर लाइन निष्क्रिय रख सकता है भले ही भेजने के लिए पैकेट हों, इस प्रकार 100% से कम लिंक उपयोग प्रदान किया गया। लिंक शेयर हमेशा उपलब्ध क्षमता का 100% उपयोग करता है। वास्तविक के विपरीत। ,

वास्तविक समय को कठिन विलंबता की गारंटी देने के लिए कहा जा सकता है, यह विलंबित है। इसलिए यदि आप 1Mbit / sec लिंक पर 20ms विलंबता की गारंटी देने की कोशिश कर रहे हैं, और लिंक शेयर MTU आकार (1500 बाइट) पैकेट भेज रहे हैं, तो आप जानते हैं कि उन पैकेटों में से एक को भेजने में 12ms लगेंगे। इस प्रकार यदि आप वास्तविक समय बताते हैं कि आप 8ms विलंबता चाहते हैं, तो आप अभी भी 20ms की समय सीमा को पूरा कर सकते हैं - एक पूर्ण गारंटी के साथ।

और अगर ऊपर की धारणा वास्तव में सटीक है, तो उस मॉडल में प्राथमिकता कहां है? उदाहरण के लिए हर वर्ग में एक वास्तविक समय बैंडविड्थ (गारंटीकृत), एक लिंक-शेयर बैंडविड्थ (गारंटी नहीं) और एक ऊपरी सीमा हो सकती है, लेकिन फिर भी कुछ वर्गों में अन्य वर्गों की तुलना में उच्च प्राथमिकता की आवश्यकता होती है। उस स्थिति में मुझे अभी भी किसी तरह प्राथमिकता देनी चाहिए, यहां तक ​​कि उन कक्षाओं के वास्तविक समय के यातायात के बीच भी। क्या मैं घटता के ढलान से प्राथमिकता दूंगा? और यदि हां, तो कौन सा वक्र? वास्तविक समय वक्र? लिंक-शेयर वक्र? ऊपरी सीमा वक्र? उन सभी को? क्या मैं उन सभी को एक ही ढलान या एक अलग एक दे दूंगा और सही ढलान का पता कैसे लगाऊंगा?

कोई प्राथमिकता वाला मॉडल नहीं है। गंभीरता से। यदि आप ट्रैफ़िक को प्राथमिकता देना चाहते हैं, तो pfifo का उपयोग करें। जो है, वही है। लेकिन यह भी सावधान रहें कि यदि आप वेब ट्रैफ़िक को ईमेल ट्रैफ़िक से अधिक प्राथमिकता देते हैं, तो इसका अर्थ है कि वेब ट्रैफ़िक लिंक को संतृप्त करना और इस प्रकार कोई भी ईमेल पैकेट प्राप्त नहीं करना है । आपके सभी ईमेल कनेक्शन मर जाते हैं।

वास्तव में कोई भी उस तरह की प्राथमिकता नहीं चाहता है। वे चाहते हैं कि HFSC क्या प्रदान करता है। यदि आपके पास वास्तव में वास्तविक समय ट्रैफ़िक है, तो HFSC यह प्रदान करता है। लेकिन यह सब सामान होगा। बाकी के लिए, एचएफएससी आपको "एक भीड़भाड़ वाली कड़ी पर" कहने की अनुमति देता है, वेब पर 90% आवंटित करता है और 10% पर ईमेल ट्रिकलल देता है, और ओह जल्दी से विषम डीएनएस पैकेट भेजते हैं लेकिन किसी को इसके साथ डॉस न दें।


5

आप विभिन्न नामों के साथ घटता को परिभाषित कर सकते हैं:

  • आरटी, वास्तविक समय वक्र, बैंडविड्थ / देरी की गारंटी।
  • ls, लिंक-शेयर वक्र, बैंडविड्थ / विलंब साझाकरण (पड़ोसी पत्तियों के विन्यास के आधार पर)
  • उल, ऊपरी सीमा वक्र, अधिकतम बैंडविड्थ / विलंब इसे प्राप्त कर सकते हैं।

मुझे एक वास्तविक समय वक्र की क्या आवश्यकता है? मान लें कि A1, A2, B1, B2 सभी 128 kbit / s लिंक-शेयर (किसी एक के लिए कोई वास्तविक समय वक्र नहीं है), तो उन सभी को 128 kbit / s मिलेगा यदि रूट को वितरित करने के लिए 512 kbit / s है (और A और B दोनों 256 kbit / s पाठ्यक्रम के हैं), है ना? मैं अतिरिक्त रूप से A1 और B1 को 128 kbit / s के साथ एक वास्तविक समय वक्र क्यों दूंगा? इसके लिए क्या अच्छा होगा? उन दो को उच्च प्राथमिकता देने के लिए? मूल कागज के अनुसार मैं एक वक्र का उपयोग करके उन्हें एक उच्च प्राथमिकता दे सकता हूं, यही एचएफएससी आखिरकार क्या है। दोनों वर्गों को [256kbit / s 20ms 128kbit / s] का वक्र प्रदान करने से, दोनों A2 और B2 की तुलना में दो बार स्वचालित रूप से प्राथमिकता देते हैं (अभी भी औसतन केवल 128 kbit / s प्राप्त कर रहे हैं)

जब आप केवल दरों के साथ HFSC में एक परिभाषा बनाते हैं, तो यह स्वतः ही 'dmax' को 0 पर सेट कर देता है। मूल रूप से इसका मतलब है कि यह देरी के लिए जिम्मेदार नहीं है। एक अच्छा एचएफएससी कॉन्फ़िगरेशन में बैंडविड्थ और विलंब सीमाएं शामिल होनी चाहिए जो आप अपनी कक्षा के लिए उपयोग करना चाहते हैं, अन्यथा एल्गोरिथ्म यह पता नहीं लगा सकता है कि कक्षा को कितनी प्राथमिकता मिलनी चाहिए।

जब भी आप पैकेट को प्राथमिकता देते हैं, तो अन्य पैकेट को प्राथमिकता में कम करना होगा। On डीमैक्स ’और 'रेट’ मूल्यों के आधार पर सभी वर्गों को वर्चुअल टाइमर का उपयोग करके गुणा किया जाएगा। अधिक जानकारी के लिए tc-hfsc (7) देखें।

क्या वास्तविक समय बैंडविड्थ लिंक-शेयर बैंडविड्थ की ओर गिनती करता है? जैसे अगर A1 और B1 दोनों में केवल 64kbit / s का वास्तविक समय और 64kbit / s का लिंक शेयर बैंडविड्थ है, तो इसका मतलब यह है कि एक बार जब वे वास्तविक समय के माध्यम से 64kbit / s सेवा कर रहे हैं, तो उनकी लिंक-शेयर आवश्यकता भी संतुष्ट है (वे हो सकते हैं) अतिरिक्त बैंडविड्थ प्राप्त करें, लेकिन इसे एक सेकंड के लिए अनदेखा करें) या इसका मतलब है कि उन्हें लिंक-शेयर के माध्यम से एक और 64 kbit / s मिलता है? तो क्या प्रत्येक वर्ग के पास वास्तविक समय के साथ लिंक-शेयर की बैंडविड्थ "आवश्यकता" है? या क्या किसी वर्ग को केवल वास्तविक समय के वक्र की तुलना में अधिक आवश्यकता होती है, यदि लिंक-शेयर वक्र वास्तविक समय वक्र की तुलना में अधिक है (वर्तमान लिंक-शेयर आवश्यकता निर्दिष्ट लिंक-शेयर आवश्यकता के बराबर है, जो पहले से ही प्रदान की गई वास्तविक समय बैंडविड्थ है कक्षा)?

यदि प्रवाह कक्षा की लिंक-शेयर परिभाषा की सीमाओं से अधिक नहीं जा रहा है, तो वास्तविक समय वक्र का उपयोग कभी नहीं किया जाता है। इस मामले में एक वास्तविक समय वक्र को परिभाषित करना आपको उदाहरण के लिए अनुमति देता है: एक निश्चित 'डीमैक्स' की गारंटी देने के लिए।

यदि आपकी लिंक-शेयर परिभाषाएँ निर्दोष हैं, तो आपको वास्तविक समय के घटता की आवश्यकता नहीं होगी। आप बस सेवा घटता (sc) को परिभाषित कर सकते हैं, लेकिन यह आपके कॉन्फ़िगरेशन को कठिन बना देगा।

क्या ऊपरी सीमा वक्र वास्तविक समय के लिए भी लागू है, केवल लिंक-शेयर या शायद दोनों के लिए? कुछ ट्यूटोरियल एक तरह से कहते हैं, कुछ दूसरे तरीके से कहते हैं। कुछ भी दावा करते हैं कि ऊपरी-सीमा वास्तविक-समय बैंडविड्थ + लिंक-शेयर बैंडविड्थ के लिए अधिकतम है? सच क्या है?

आपकी कक्षा की ऊपरी-सीमा वक्र लिंक-शेयर पर ही लागू होती है, जब आप ऊपरी-सीमा वक्र को परिभाषित करते हैं तो आप लिंक-शेयर वक्र को परिभाषित करते हैं। हालाँकि अभिभावक वर्गों की ऊपरी सीमा वक्र अभी भी लागू है।

A2 और B2 को मानें तो 128 kbit / s हैं, क्या इससे कोई फर्क पड़ता है अगर A1 और B1 केवल 128 kbit / s लिंक-शेयर हैं, या 64 kbit / s वास्तविक-समय और 128 kbit / s-share-share, और यदि हैं , क्या अंतर है?

थोड़ा अंतर है, अगर उदाहरण के लिए A2 = 0 kbit / s और B2 = 256 kbit / s। तब A2 के लिए वर्चुअल-टाइम उसकी अधिकतम सीमा पर होगा। जब भी पैकेट को A2 में वर्गीकृत किया जाता है, तो उन्हें तुरंत संसाधित किया जाएगा। हालांकि बी 2 का वास्तविक समय वक्र अभी भी सुनिश्चित करेगा कि कम से कम 64 kbit / s संचारित करने में सक्षम है

यदि मैं कक्षाओं की प्राथमिकताओं को बढ़ाने के लिए अलग-अलग वास्तविक समय वक्र का उपयोग करता हूं, तो मुझे "वक्र" की आवश्यकता क्यों होगी? रियल-टाइम एक फ्लैट मूल्य और लिंक-शेयर भी एक फ्लैट मूल्य क्यों नहीं है? दोनों वक्र क्यों हैं? मूल कागज में घटता की आवश्यकता स्पष्ट है, क्योंकि प्रति वर्ग उस तरह का एक ही गुण है। लेकिन अब, तीन विशेषताएँ (वास्तविक समय, लिंक-शेयर, और ऊपरी-सीमा) होने के लिए मुझे अभी भी प्रत्येक पर घटता की क्या आवश्यकता है? मैं वास्तविक समय और लिंक-साझा ट्रैफ़िक के लिए घटता आकार (औसत बैंडविड्थ नहीं, बल्कि उनकी ढलान) क्यों चाहूंगा?

वास्तविक समय घटता पड़ोसी पत्तियों के बीच यातायात साझा नहीं करते हैं, लिंक-शेयर घटता है।

उपलब्ध छोटे दस्तावेज़ों के अनुसार, वास्तविक समय वक्र मानों को आंतरिक कक्षाओं (कक्षा ए और बी) के लिए पूरी तरह से अनदेखा किया जाता है, वे केवल लीफ क्लास (ए 1, ए 2, बी 1, बी 2) पर लागू होते हैं। यदि यह सच है, तो ALTQ HFSC नमूना कॉन्फ़िगरेशन (3.3 नमूना कॉन्फ़िगरेशन के लिए खोज) आंतरिक कक्षाओं पर वास्तविक समय घटता क्यों सेट करता है और दावा करता है कि उन आंतरिक वर्गों की गारंटीकृत दर निर्धारित करता है? क्या यह पूरी तरह से व्यर्थ नहीं है? (नोट: pshare ALTQ में लिंक-शेयर वक्र सेट करता है और वास्तविक समय वक्र को grate करता है; आप इसे नमूना कॉन्फ़िगरेशन के ऊपर पैराग्राफ में देख सकते हैं)।

यह सच है कि आंतरिक कक्षाओं के लिए वास्तविक समय के घटता को नजरअंदाज किया जाता है, वे केवल पत्ती कक्षाओं पर लागू होते हैं। हालाँकि उन आंतरिक वर्गों पर परिभाषित वास्तविक समय के वक्रों को पत्ती वर्गों पर गणना के लिए ध्यान में रखा जाता है।

कुछ ट्यूटोरियल कहते हैं कि सभी वास्तविक समय घटता का योग लाइन गति के 80% से अधिक नहीं हो सकता है, दूसरों का कहना है कि यह लाइन की गति के 70% से अधिक नहीं होना चाहिए। कौन सा सही है या वे दोनों गलत हैं?

उनका मतलब है: आप सभी ट्रैफ़िक को प्राथमिकता नहीं दे सकते ... जब भी आप पैकेट प्राथमिकता देते हैं, तो अन्य पैकेट प्राथमिकता में कम करने होंगे। यदि आप ओवर-गारंटी करते हैं, तो एल्गोरिथ्म व्यर्थ हो जाता है। वर्ग को परिभाषित करें जो प्राथमिकता प्राप्त करें और उन वर्गों को परिभाषित करें जो पीड़ित हो सकते हैं।

एक ट्यूटोरियल ने कहा कि आप सभी सिद्धांत भूल जाएंगे। कोई फर्क नहीं पड़ता कि चीजें वास्तव में कैसे काम करती हैं (शेड्यूलर्स और बैंडविड्थ वितरण), निम्नलिखित "सरलीकृत माइंड मॉडल" के अनुसार तीन घटों की कल्पना करें: वास्तविक समय की गारंटी बैंडविड्थ है जो इस वर्ग को हमेशा मिलेगी। लिंक-शेयर वह बैंडविड्थ है जो यह वर्ग पूरी तरह से संतुष्ट होना चाहता है, लेकिन संतुष्टि की गारंटी नहीं दी जा सकती है। यदि अतिरिक्त बैंडविड्थ है, तो कक्षा को संतुष्ट होने के लिए आवश्यक से अधिक बैंडविड्थ की पेशकश भी मिल सकती है, लेकिन यह कभी भी ऊपरी सीमा से अधिक का उपयोग नहीं कर सकता है। यह सब काम करने के लिए, सभी वास्तविक समय के बैंडविंड का योग लाइन गति के xx% से ऊपर नहीं हो सकता है (ऊपर प्रश्न देखें, प्रतिशत भिन्न होता है)। प्रश्न: क्या यह कमोबेश सटीक है या HSFC की कुल गलतफहमी है?

यह सही है।

और अगर ऊपर की धारणा वास्तव में सटीक है, तो उस मॉडल में प्राथमिकता कहां है? उदाहरण के लिए हर वर्ग में एक वास्तविक समय बैंडविड्थ (गारंटीकृत), एक लिंक-शेयर बैंडविड्थ (गारंटी नहीं) और एक ऊपरी सीमा हो सकती है, लेकिन फिर भी कुछ वर्गों में अन्य वर्गों की तुलना में उच्च प्राथमिकता की आवश्यकता होती है। उस स्थिति में मुझे अभी भी किसी तरह प्राथमिकता देनी चाहिए, यहां तक ​​कि उन कक्षाओं के वास्तविक समय के यातायात के बीच भी। क्या मैं घटता के ढलान से प्राथमिकता दूंगा? और यदि हां, तो कौन सा वक्र? वास्तविक समय वक्र? लिंक-शेयर वक्र? ऊपरी सीमा वक्र? उन सभी को? क्या मैं उन सभी को एक ही ढलान या एक अलग एक दे दूंगा और सही ढलान का पता कैसे लगाऊंगा?

उदाहरण के लिए एचएफएससी और एचटीबी के बीच अंतर यह है कि एचएफएससी आपको यह परिभाषित करने की अनुमति देगा कि आप इसे कितना प्राथमिकता चाहते हैं। आप न्यूनतम और अधिकतम सीमाओं को 'dmax' मान के साथ परिभाषित करके ऐसा करते हैं।


2

अंत में एक मार्गदर्शिका जो अधिकांश विसंगतियों की व्याख्या करती है और यह भी बताती है कि वर्तमान कार्यान्वयन मूल कागज से अलग कैसे है:

http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html

इस गाइड के अनुसार, HFSC के बारे में कई अन्य गाइड और फोरम पोस्ट पूरी तरह से बकवास हैं; यह सिर्फ दिखाता है कि एचएफएससी कितना जटिल है, जितने लोग विशेषज्ञ हैं और एचएफएससी को पूरी तरह से समझने का दिखावा करते हैं, वास्तव में केवल आंशिक ज्ञान है और अवधारणा की गलतफहमी के आधार पर गलत बयान देते हैं और उन सभी सेटिंग्स को एक साथ कैसे खेलते हैं।

मुझे लगता है कि मैं आखिरकार HFSC को छोड़ दूंगा। यदि आप अपना HFSC सेटअप सही से प्राप्त कर सकते हैं, तो यह आपके द्वारा प्राप्त की जा सकने वाली सबसे अच्छी QoS हो सकती है, लेकिन आपके द्वारा पूरी तरह से गड़बड़ किए जाने की संभावना, आपके द्वारा सफल होने की संभावना से कहीं अधिक है।


1

यदि आप मूल लेखकों की पकड़ पाने में सक्षम नहीं हैं, तो मैं यह कोशिश करूंगा:

  1. लिनक्स कर्नेल सोर्स ट्री में जाएं और C फाइलें खोजें जो "TC शेड्यूलिंग फ्रेमवर्क" को कार्यान्वित करें
  2. हेडर को देखें और कोड के लेखक को ढूंढें।
  3. "टीसी शेड्यूलिंग फ्रेमवर्क" के ई-मेल प्रोग्रामर उन्हें उनके कार्यान्वयन पर साहित्य के लिए पूछ रहे हैं।

अन्य नए पत्रों की जाँच करने का भी प्रयास करें जो इस का हवाला देते हैं। वहाँ नए कागजात हो सकते हैं जो इस क्षेत्र में अनुसंधान का एक सिलसिला है और आपके द्वारा पूछे जा रहे सवालों के बारे में अधिक जानकारी शामिल हो सकती है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.