क्यों USB डिवाइस 480 MBit / s से धीमी हैं


41

प्रेरणा

480 MBit / s USB 2.0 उपकरणों की सिग्नलिंग दर के साथ 60 एमबी / एस तक डेटा संचारित करने में सक्षम होना चाहिए। हालाँकि आज के उपकरण [ विकी: यूएसबी ] को पढ़ते हुए 30-42 एमबी / एस तक सीमित प्रतीत होते हैं । वह 30 प्रतिशत ओवरहेड है।

USB 2.0 बाहरी उपकरणों के लिए 10 वर्षों से एक वास्तविक मानक है। USB इंटरफ़ेस के लिए सबसे महत्वपूर्ण एप्लिकेशन में से एक पोर्टेबल भंडारण है। दुर्भाग्य से USB 2.0 जल्दी से इन बैंडविड्थ अनुप्रयोगों की मांग करने के लिए गति को सीमित कर रहा था, आज का HDD क्रमिक रीड में 90 MB / s से अधिक सक्षम उदाहरण के लिए है। लंबे बाजार की उपस्थिति और उच्च बैंडविड्थ की निरंतर आवश्यकता को देखते हुए हमें उम्मीद करनी चाहिए कि यूएसबी 2.0 इको सिस्टम वर्षों से अनुकूलित किया गया है और एक पठनीय प्रदर्शन तक पहुंच गया है जो सैद्धांतिक सीमा के करीब है।

हमारे मामले में सैद्धांतिक अधिकतम बैंडविड्थ क्या है? हर प्रोटोकॉल में USB सहित ओवरहेड होता है और आधिकारिक USB 2.0 मानक के अनुसार यह 53.248 MB / s [ 2 , टेबल 5-10] है। इसका मतलब है कि सैद्धांतिक रूप से आज के यूएसबी 2.0 डिवाइस 25 प्रतिशत तेज हो सकते हैं।

विश्लेषण

इस समस्या की जड़ के पास कहीं भी जाने के लिए निम्नलिखित विश्लेषण यह प्रदर्शित करेगा कि स्टोरेज डिवाइस से अनुक्रमिक डेटा पढ़ते समय बस में क्या हो रहा है। प्रोटोकॉल परत दर परत टूट जाता है और हम इस सवाल में विशेष रूप से रुचि रखते हैं कि 53.248 एमबी / एस थोक बहिर्वाह उपकरणों के लिए अधिकतम सैद्धांतिक संख्या क्यों है। अंत में हम विश्लेषण की सीमाओं के बारे में बात करेंगे जो हमें अतिरिक्त ओवरहेड के कुछ संकेत दे सकता है।

टिप्पणियाँ

इस प्रश्न के दौरान केवल दशमलव उपसर्ग का उपयोग किया जाता है।

एक USB 2.0 होस्ट कई डिवाइस (हब के माध्यम से) और प्रति डिवाइस कई एंडपॉइंट को संभालने में सक्षम है। समापन बिंदु विभिन्न स्थानांतरण मोड में काम कर सकते हैं। हम अपने विश्लेषण को एक एकल डिवाइस तक सीमित कर देंगे जो सीधे मेजबान से जुड़ा हुआ है और जो हाई-स्पीड मोड में एक अपस्ट्रीम बल्क एंडपॉइंट पर लगातार पूर्ण पैकेट भेजने में सक्षम है।

फ्रेमिंग

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

यहाँ छवि विवरण दर्ज करें एक बड़ा संस्करण देखने के लिए एक नए टैब में छवि खोलें।

लेन-देन

USB एक मास्टर संचालित प्रोटोकॉल है और प्रत्येक लेनदेन मेजबान द्वारा शुरू किया जाता है। एसओएफ और ईओएफ के बीच के समय का उपयोग यूएसबी लेनदेन के लिए किया जा सकता है। हालांकि एसओएफ और ईओएफ के लिए समय बहुत सख्त है और मेजबान केवल उन लेनदेन को शुरू करता है जो पूरी तरह से मुक्त टाइमस्टेल के भीतर पूरा हो सकते हैं।

हम जिस लेन-देन में रुचि रखते हैं, वह एक सफल थोक में लेन-देन है। लेन-देन एक टोकन पैकेट IN से शुरू होता है, फिर होस्ट डेटा पैकेट DATA0 / DATA1 की प्रतीक्षा करता है और एक हैंडशेक पैकेट ACK के साथ प्रसारण की पुष्टि करता है। इन सभी पैकेटों के लिए EOP पैकेट डेटा के आधार पर 1 से 8 बिट है, हमने यहां सबसे खराब स्थिति मान ली।

इन तीन पैकेटों में से प्रत्येक के बीच हमें प्रतीक्षा समय पर विचार करना होगा। वे मेजबान से IN पैकेट के अंतिम बिट और डिवाइस के DATA0 पैकेट के पहले बिट और DATA0 पैकेट के अंतिम बिट और ACK पैकेट के पहले बिट के बीच होते हैं। हमें किसी और देरी पर विचार करने की आवश्यकता नहीं है क्योंकि होस्ट ACK भेजने के बाद अगले IN को सही में भेजना शुरू कर सकता है। केबल ट्रांसमिशन समय को अधिकतम 18 ns के रूप में परिभाषित किया गया है।

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

उचित घड़ी वसूली सुनिश्चित करने के लिए मानकों को एक विधि कॉल बिट स्टफिंग को परिभाषित करता है। जब पैकेट को उसी आउटपुट के बहुत लंबे अनुक्रम की आवश्यकता होगी, तो एक अतिरिक्त फ़्लैंक जोड़ा जाता है। यह अधिकतम 6 बिट्स के बाद एक फ्लैंक सुनिश्चित करता है। सबसे खराब स्थिति में यह कुल पैकेट का आकार 7/6 बढ़ाएगा। EOP बिट स्टफिंग के अधीन नहीं है।

यहाँ छवि विवरण दर्ज करें एक बड़ा संस्करण देखने के लिए एक नए टैब में छवि खोलें।

बैंडविड्थ की गणना

एक बल्क इन ट्रांजैक्शन में 24 बाइट्स का ओवरहेड और 512 बाइट्स का पेलोड होता है। यह कुल 536 बाइट्स है। 7487 बाइट्स के बीच की समयरेखा विस्तृत है। बिट स्टफिंग की आवश्यकता के बिना 13.968 पैकेट के लिए जगह है। प्रति सेकंड 8000 माइक्रो-फ्रेम्स होने के बाद हम 13 * 512 * 8000 B / s = 53.248 MB / s के साथ डेटा पढ़ सकते हैं

पूरी तरह से बेतरतीब डेटा के लिए हम उम्मीद करते हैं कि 6 में से एक बिट्स में 2 = 6 = 64 क्रमों में बिट स्टफिंग आवश्यक है। यह (63 * 6 + 7) / (64 * 6) की वृद्धि है। सभी बाइट्स को गुणा करना जो कि संख्याओं के अनुसार बिट स्टफिंग के अधीन हैं (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537.38 बाइट्स की कुल लेन-देन लंबाई देता है। जिसके परिणामस्वरूप माइक्रो-फ्रेम प्रति 13.932 पैकेट हैं।

इन गणनाओं से एक और विशेष मामला गायब है। मानक 192 बिट समय [ 2 , अध्याय 7.1.19.2] की अधिकतम डिवाइस प्रतिक्रिया समय को परिभाषित करता है । यदि अंतिम पैकेज अभी भी फ्रेम में फिट बैठता है, तो यह विचार करना होगा कि डिवाइस को पूर्ण प्रतिक्रिया समय की आवश्यकता है या नहीं। हम 7439 बाइट्स की विंडो का उपयोग करके इसका हिसाब लगा सकते हैं। परिणामी बैंडविड्थ हालांकि समान है।

क्या बाकि है

  • त्रुटि का पता लगाने और पुनर्प्राप्त करने को कवर नहीं किया गया है। हो सकता है कि त्रुटि लगातार पर्याप्त हो या त्रुटि ठीक हो रही हो, औसत प्रदर्शन पर प्रभाव डालने के लिए पर्याप्त समय लगता है।

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

  • अन्य समापन बिंदुओं या अतिरिक्त संचार के लिए स्थानांतरण पर विचार नहीं किया गया है। हो सकता है कि भंडारण उपकरणों के लिए मानक प्रोटोकॉल में कुछ निरंतर साइड चैनल संचार की आवश्यकता होती है जो मूल्यवान स्लॉट समय का उपभोग करता है।

  • डिवाइस ड्राइवर या फ़ाइल सिस्टम परत के लिए भंडारण उपकरणों के लिए एक अतिरिक्त प्रोटोकॉल ओवरहेड हो सकता है। (पैकेट पेलोड == संग्रहण डेटा?)

सवाल

  • आज के कार्यान्वयन 53 एमबी / एस पर स्ट्रीमिंग के लिए सक्षम क्यों नहीं हैं?

  • आज के कार्यान्वयन में अड़चन कहां है?

और एक संभावित अनुवर्ती: किसी ने ऐसी अड़चन को खत्म करने की कोशिश क्यों नहीं की?

संदर्भ

[१] आधिकारिक USB २.० विनिर्देश

[२] स्पेसिफिकेशन का फास्ट पीडीएफ मिरर


2
आप जानते हैं कि USB 2.0 द्वारा USB 2.0 को अधिगृहीत कर लिया गया है जो कि काफी तेज है?
जॉनीबोट्स

8
यूएसबी मानक के साथ अनुसंधान और स्पष्ट परिचित की गहराई से, यह स्पष्ट है कि क्रिस यूएसबी 3.0, @ जॉनीबॉट्स से परिचित है।
टिब्लू

5
@JonnyBoats, इस पर उचित प्रतिक्रिया होगी, "आप जानते हैं कि अधिकांश कंप्यूटरों में अभी भी USB2.0 है और एक मानक अद्यतन सभी हार्डवेयर अपग्रेड तुरंत नहीं होता है?" मुझे संदेह है कि यह इरादा था लेकिन आपने जो टिप्पणी लिखी है वह अपने वर्तमान स्वरूप में थोड़ी अपमानजनक लगती है।
कोर्तुक

Kortuk: यह इंगित करने के लिए धन्यवाद, यह निश्चित रूप से किसी का अपमान करने का मेरा इरादा नहीं है। मेरा कहना है कि USB, अधिकांश विशिष्टताओं की तरह, समय के साथ विकसित होता है। 2.0 तो तेजी से 1.0 और 3.0 अब बाजार में आ रही है और अभी भी तेज है। मैं कल्पना करूंगा कि 2.0 पर सुधार के बजाय 3.0 को अपनाने पर अधिक कंपनियों को ध्यान केंद्रित किया जाएगा
जॉनीबोट्स

1
जबकि माइक्रोफ़्रेम में 13 पैकेट के लिए जगह हो सकती है, कई मेजबान नियंत्रक वास्तव में ऐसा नहीं कर सकते हैं। 2006 में वापस लौटे, ज्यादातर 8 में से 10 तक सीमित थे और 10 में - मुझे नहीं पता कि क्या तब से बहुत कुछ बदल गया है या नहीं।
user2793784

जवाबों:


15

अपने जीवन में किसी समय, मैं बड़ी अर्ध कंपनी के लिए USB व्यवसाय चलाता था। सबसे अच्छा परिणाम मुझे याद है कि NEC SATA नियंत्रक 320Mbps वास्तविक डेटा को बड़े पैमाने पर भंडारण के लिए धकेलने में सक्षम था, शायद वर्तमान sata ड्राइव इस या उससे थोड़ा अधिक सक्षम हैं। यह BOT (USB पर कुछ मास स्टोरेज प्रोटोकॉल रन) का उपयोग कर रहा था।

मैं एक तकनीकी विस्तृत जवाब दे सकता हूं लेकिन मुझे लगता है कि आप खुद को घटा सकते हैं। आपको जो देखने की ज़रूरत है, वह यह है कि यह इकोसिस्टम प्ले है, किसी भी महत्वपूर्ण सुधार के लिए माइक्रोसॉफ्ट जैसे किसी व्यक्ति को अपना स्टैक बदलने, ऑप्टिमाइज़ करने आदि की आवश्यकता होगी, जो होने वाला नहीं है। इंटरऑपरेबिलिटी गति की तुलना में कहीं अधिक महत्वपूर्ण है। क्योंकि मौजूदा स्टैक सावधानी से डिवाइस के स्लीव की गलतियों को कवर करते हैं क्योंकि जब USB2 स्पेक निकलता है तो शायद शुरुआती डिवाइस इस बात की पुष्टी नहीं करते हैं कि स्पेक बग्गी था, सर्टिफिकेशन सिस्टम बग्गी इत्यादि था। यदि आप MS के लिए लिनक्स या कस्टम USB होस्ट ड्राइवरों का उपयोग करके एक होम काढ़ा प्रणाली का निर्माण करते हैं और एक तेज़ डिवाइस नियंत्रक आप संभवतः सैद्धांतिक सीमाओं के करीब हो सकते हैं।

स्ट्रीमिंग के संदर्भ में, आईएसओ बहुत तेज़ माना जाता है, लेकिन नियंत्रक इसे बहुत अच्छी तरह से लागू नहीं करते हैं, क्योंकि 95% ऐप्स बल्क ट्रांसफर का उपयोग करते हैं।

एक बोनस अंतर्दृष्टि के रूप में, उदाहरण के लिए, यदि आप जाते हैं और आज हब आईसी का निर्माण करते हैं, यदि आप डॉट के लिए कल्पना का पालन करते हैं, तो आप व्यावहारिक रूप से शून्य चिप्स बेचेंगे। यदि आप बाजार के सभी कीड़े जानते हैं और सुनिश्चित करें कि आपका हब आईसी उन्हें सहन कर सकता है, तो आप संभवतः बाजार में पहुंच सकते हैं। मैं आज भी आश्चर्यचकित हूं, कि यूएसबी कितने खराब सॉफ्टवेयर और चिप्स के काम कर रहा है।


6

यह बहुत पुराना विषय है, लेकिन इसका अभी तक कोई जवाब नहीं है। यह मेरा प्रयास है:

आज के कार्यान्वयन 53 एमबी / एस पर स्ट्रीमिंग के लिए सक्षम क्यों नहीं हैं?

गणना लगभग ठीक है, लेकिन आप फ्रेम मार्कर के बीच बाइट्स की उपलब्ध संख्या में कुछ चीजों को भूल रहे हैं:

  1. प्रत्येक माइक्रोफ़्रेम में EOF1 और EOF2 नामक दो थ्रेसहोल्ड होते हैं। EOF1 के बाद / के बाद कोई बस तीक्ष्णता नहीं होनी चाहिए। इस बिंदु का प्लेसमेंट एक जटिल बात है, लेकिन अगले एसओएफ से पहले विशिष्ट स्थिति 560 बिट बार है। एक मेजबान को इस तरह से अपने लेन-देन का समय निर्धारित करना चाहिए, ताकि चैनल से कोई भी संभावित प्रतिक्रिया इस सीमा तक न पहुंचे। जो आपकी गणना की गई 7487 बाइट्स में से लगभग 70 बाइट्स खाती है।

  2. आप "यादृच्छिक डेटा" मान लेते हैं। यह पूरी तरह से निराधार है, डेटा कुछ भी हो सकता है। इसलिए मेजबान को सबसे खराब स्थिति पेलोड के लिए लेनदेन को शेड्यूल करना होगा, जिसमें अधिकतम बिट स्टफिंग ओवरहेड, 512 * 7/6 = ~ 600 बाइट्स होंगे। साथ ही लेन-देन के 24 बाइट्स ओवरहेड, जैसा कि आपने सही गणना की है। यह (7487-70) / 624 = 11.88 प्रति माइक्रो-फ्रेम लेनदेन देता है।

  3. होस्ट को किसी अन्य गतिविधि के लिए नियंत्रण लेनदेन के लिए लगभग 10% बैंडविथ को आरक्षित करना आवश्यक है, इसलिए हमें लगभग 10.7 लेनदेन प्राप्त होते हैं।

  4. होस्ट कंट्रोलर के पास अपनी लिंक्ड सूची का प्रबंधन करते समय कुछ विलंबता भी होती है, इसलिए लेनदेन के बीच अतिरिक्त अंतर होता है।

  5. डिवाइस 5 हब्स / हॉप्स रूट से दूर हो सकता है, और प्रतिक्रिया में देरी 1700 एनएस तक हो सकती है, जो प्रत्येक लेनदेन बजट का एक और 106 बाइट खाती है। कच्चे अनुमान में, यह केवल 10.16 प्रति यूफ्रेम लेनदेन करता है, आरक्षित बैंडविड्थ के लिए नहीं।

मेजबान uFrame के भीतर वास्तविक लेन-देन के आगमन के आधार पर अनुकूली पुन: निर्धारण नहीं कर सकता है, यह सॉफ्टवेयर के नजरिए से निषेधात्मक होगा, इसलिए चालक प्रति uFrame में 9 बल्क लेनदेन तक सबसे अधिक रूढ़िवादी अनुसूची का उपयोग करता है, जिसकी मात्रा 36 Mbytes / है दूसरा। यह वही है जो एक बहुत अच्छा यूएसबी पेन ड्राइव वितरित कर सकता है।

कुछ पागल कृत्रिम बेंचमार्क प्रति uFrame में 11 लेनदेन तक जा सकते हैं, जो इसे 44 एमबीपीएस बनाता है। और यह HS USB प्रोटोकॉल के लिए पूर्ण अधिकतम है।

आज के कार्यान्वयन में अड़चन कहां है?

जैसा कि ऊपर देखा जा सकता है, कोई बोटेलिनेक नहीं है, सभी कच्चे बिट-टाइम स्पेस को प्रोटोकॉल उपरि द्वारा खाया जाता है।

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