เหตุใดอุปกรณ์ USB จึงช้ากว่า 480 MBit / s


41

แรงจูงใจ

ด้วยอัตราการส่งสัญญาณ 480 MBit / s อุปกรณ์ USB 2.0 ควรจะสามารถส่งข้อมูลด้วยสูงสุด 60 MB / s อย่างไรก็ตามอุปกรณ์ของวันนี้ดูเหมือนจะถูก จำกัด ที่ 30-42 MB / s ในขณะที่อ่าน [ Wiki: USB ] นั่นคือค่าใช้จ่ายร้อยละ 30

USB 2.0 เป็นมาตรฐานสำหรับอุปกรณ์ภายนอกมานานกว่า 10 ปี หนึ่งในแอปพลิเคชั่นที่สำคัญที่สุดสำหรับอินเตอร์เฟส USB ตั้งแต่ต้นได้รับการจัดเก็บแบบพกพา น่าเสียดายที่ USB 2.0 เป็นคอขวดที่ จำกัด ความเร็วสำหรับแอปพลิเคชั่นที่ต้องการแบนด์วิดท์อย่างรวดเร็ว HDD ในปัจจุบันเป็นตัวอย่างที่มีความสามารถมากกว่า 90 MB / s ในการอ่านตามลำดับ เมื่อพิจารณาถึงสถานะของตลาดที่ยาวนานและความต้องการแบนด์วิดท์ที่สูงขึ้นอย่างต่อเนื่องเราควรคาดหวังว่าระบบ USB 2.0 eco นั้นได้รับการปรับปรุงให้ดีขึ้นในช่วงหลายปีที่ผ่านมาและได้รับประสิทธิภาพการอ่านที่ใกล้เคียงกับ

แบนด์วิดธ์สูงสุดทางทฤษฎีในกรณีของเราคืออะไร? โปรโตคอลทุกตัวมีค่าใช้จ่ายรวมถึง USB และตามมาตรฐาน USB 2.0 อย่างเป็นทางการคือ 53.248 MB / s [ 2 , ตารางที่ 5-10] นั่นหมายความว่าอุปกรณ์ USB 2.0 ทุกวันนี้อาจเร็วกว่าเดิมถึงร้อยละ 25

การวิเคราะห์

เพื่อให้ได้ใกล้กับรากของปัญหานี้การวิเคราะห์ต่อไปนี้จะแสดงให้เห็นถึงสิ่งที่เกิดขึ้นบนรถบัสในขณะที่อ่านข้อมูลตามลำดับจากอุปกรณ์เก็บข้อมูล โพรโทคอลถูกแบ่งย่อยทีละเลเยอร์และเราสนใจเป็นพิเศษในคำถามที่ว่าทำไม 53.248 MB / s เป็นจำนวนทางทฤษฎีสูงสุดสำหรับอุปกรณ์อัพสตรีมจำนวนมาก ในที่สุดเราจะพูดคุยเกี่ยวกับข้อ จำกัด ของการวิเคราะห์ซึ่งอาจทำให้เรามีคำแนะนำของค่าใช้จ่ายเพิ่มเติม

หมายเหตุ

ตลอดคำถามนี้ใช้คำนำหน้าทศนิยมเท่านั้น

โฮสต์ USB 2.0 สามารถจัดการอุปกรณ์ได้หลายตัว (ผ่านฮับ) และอุปกรณ์ปลายทางหลายจุดต่ออุปกรณ์ จุดปลายสามารถทำงานในโหมดการถ่ายโอนที่แตกต่างกัน เราจะ จำกัด การวิเคราะห์ของเราให้อยู่ในอุปกรณ์เดียวที่เชื่อมต่อโดยตรงกับโฮสต์และสามารถส่งแพ็กเก็ตแบบเต็มอย่างต่อเนื่องผ่านจุดปลายทางที่เป็นกลุ่มอัปสตรีมในโหมดความเร็วสูง

กรอบ

การสื่อสารความเร็วสูงแบบ USB ได้รับการซิงโครไนซ์ในโครงสร้างเฟรมคงที่ แต่ละเฟรมยาว 125 us และเริ่มต้นด้วยแพ็กเก็ต Start-Of-Frame (SOF) และถูก จำกัด โดยและลำดับ End-Of-Frame (EOF) แต่ละแพ็กเก็ตเริ่มต้นด้วย SYNC และสิ้นสุดด้วยและ End-Of-Packet (EOF) ลำดับเหล่านั้นได้รับการเพิ่มลงในไดอะแกรมเพื่อความชัดเจน EOP เป็นตัวแปรขนาดและข้อมูลแพ็คเก็ตขึ้นอยู่กับสำหรับ SOF มันเป็น 5 ไบต์เสมอ

ป้อนคำอธิบายรูปภาพที่นี่ เปิดภาพในแท็บใหม่เพื่อดูเวอร์ชันที่ใหญ่กว่า

การทำธุรกรรม

USB เป็นโปรโตคอลที่ขับเคลื่อนด้วยต้นแบบและแต่ละธุรกรรมนั้นเริ่มต้นโดยโฮสต์ ช่วงเวลาระหว่าง SOF และ EOF สามารถใช้สำหรับธุรกรรม USB อย่างไรก็ตามช่วงเวลาสำหรับ SOF และ EOF นั้นเข้มงวดมากและโฮสต์จะเริ่มต้นเฉพาะธุรกรรมที่สามารถทำให้เสร็จสมบูรณ์ภายในช่วงเวลาว่าง

ธุรกรรมที่เราสนใจนั้นเป็นธุรกรรมที่ประสบความสำเร็จจำนวนมาก ธุรกรรมเริ่มต้นด้วยโทเค็นแพ็คเก็ต IN จากนั้นโฮสต์จะรอแพ็กเก็ตข้อมูล DATA0 / DATA1 และยืนยันการส่งด้วย handshake แพ็กเก็ต ACK EOP สำหรับแพ็กเก็ตเหล่านี้คือ 1 ถึง 8 บิตขึ้นอยู่กับข้อมูลแพ็กเก็ตเราถือว่าเป็นกรณีที่เลวร้ายที่สุดที่นี่

ระหว่างแพ็กเก็ตทั้งสามนี้เราต้องพิจารณาเวลารอ ซึ่งอยู่ระหว่างบิตสุดท้ายของแพ็กเก็ต IN จากโฮสต์และบิตแรกของแพ็กเก็ต DATA0 ของอุปกรณ์และระหว่างบิตสุดท้ายของแพ็กเก็ต DATA0 และบิตแรกของแพ็กเก็ต ACK เราไม่ต้องพิจารณาความล่าช้าใด ๆ เพิ่มเติมเนื่องจากโฮสต์สามารถเริ่มส่ง IN ต่อไปได้ทันทีหลังจากส่ง ACK เวลาส่งผ่านสายเคเบิลถูกกำหนดไว้สูงสุด 18 ns

การโอนจำนวนมากสามารถส่งได้สูงสุด 512 ไบต์ต่อธุรกรรม และโฮสต์จะพยายามออกธุรกรรมให้มากที่สุดเท่าที่จะทำได้ระหว่างตัวคั่นเฟรม แม้ว่าการโอนจำนวนมากจะมีลำดับความสำคัญต่ำ แต่อาจใช้เวลาทั้งหมดที่มีอยู่ในช่องเมื่อไม่มีธุรกรรมอื่นที่ค้างอยู่

เพื่อให้แน่ใจว่าการกู้คืนสัญญาณนาฬิกาที่ถูกต้องมาตรฐานจะกำหนดวิธีการเรียกบิตการบรรจุ เมื่อแพ็คเก็ตจะต้องมีลำดับที่ยาวมากของเอาต์พุตเดียวกันจะมีการเพิ่มสีข้าง ที่ช่วยให้แน่ใจว่าด้านหลังสูงสุด 6 บิต ในกรณีที่เลวร้ายที่สุดสิ่งนี้จะเพิ่มขนาดแพ็คเก็ตทั้งหมด 7/6 EOP ไม่ได้อยู่ภายใต้การบรรจุบิต

ป้อนคำอธิบายรูปภาพที่นี่ เปิดภาพในแท็บใหม่เพื่อดูเวอร์ชันที่ใหญ่กว่า

การคำนวณแบนด์วิดธ์

การทำธุรกรรม IN จำนวนมากมีค่าใช้จ่าย 24 ไบต์และน้ำหนักบรรทุกของ 512 ไบต์ นั่นคือทั้งหมด 536 ไบต์ ช่วงเวลาระหว่างกว้าง 7487 ไบต์ โดยไม่จำเป็นต้องบรรจุบิตมีพื้นที่สำหรับแพ็คเก็ต 13.968 มีเฟรมขนาดเล็กจำนวน 8000 เฟรมต่อวินาทีเราสามารถอ่านข้อมูลด้วย 13 * 512 * 8000 B / s = 53.248 MB / s

สำหรับข้อมูลแบบสุ่มเราคาดหวังว่าการบรรจุบิตเป็นสิ่งจำเป็นในหนึ่งใน 2 ** 6 = 64 ลำดับของ 6 บิตที่ต่อเนื่องกัน นั่นคือการเพิ่มขึ้นของ (63 * 6 + 7) / (64 * 6) การคูณไบต์ทั้งหมดที่มีการบรรจุบิตด้วยตัวเลขนั้นจะให้ความยาวธุรกรรม (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537.38 ไบต์ ซึ่งส่งผลให้แพ็กเก็ต 13.932 ต่อ Micro-Frame

มีอีกกรณีพิเศษที่ขาดหายไปจากการคำนวณเหล่านี้ มาตรฐานกำหนดเวลาตอบสนองอุปกรณ์สูงสุด 192 บิตครั้ง [ 2 , ตอนที่ 7.1.19.2] สิ่งนี้จะต้องได้รับการพิจารณาเมื่อตัดสินใจว่าแพ็กเกจสุดท้ายยังคงพอดีกับเฟรมในกรณีที่อุปกรณ์ต้องการเวลาตอบสนองเต็มรูปแบบ เราสามารถอธิบายได้โดยใช้หน้าต่างขนาด 7439 ไบต์ แบนด์วิดท์ที่เกิดนั้นเหมือนกัน

มีอะไรเหลือ

  • การตรวจจับข้อผิดพลาดและการกู้คืนไม่ได้รับการครอบคลุม ข้อผิดพลาดอาจเกิดขึ้นบ่อยครั้งหรือการกู้คืนข้อผิดพลาดนั้นใช้เวลานานพอที่จะส่งผลกระทบต่อประสิทธิภาพโดยเฉลี่ย

  • เราสันนิษฐานว่าโฮสต์ทันทีและปฏิกิริยาของอุปกรณ์หลังจากแพ็กเก็ตและธุรกรรม โดยส่วนตัวฉันไม่เห็นความต้องการของงานการประมวลผลขนาดใหญ่ในตอนท้ายของแพ็กเก็ตหรือการทำธุรกรรมทั้งสองด้านดังนั้นฉันจึงไม่สามารถคิดได้ว่าเหตุใดโฮสต์หรืออุปกรณ์จึงไม่สามารถตอบสนองได้ทันทีด้วยการปรับใช้ฮาร์ดแวร์ที่เหมาะสมที่สุด โดยเฉพาะอย่างยิ่งในการดำเนินงานปกติงานเก็บหนังสือและตรวจจับข้อผิดพลาดส่วนใหญ่สามารถทำได้ในระหว่างการทำธุรกรรมและแพ็คเก็ตถัดไปและการทำธุรกรรมสามารถเข้าคิว

  • การถ่ายโอนไปยังจุดปลายอื่น ๆ หรือการสื่อสารเพิ่มเติมไม่ได้รับการพิจารณา บางทีโปรโตคอลมาตรฐานสำหรับอุปกรณ์จัดเก็บข้อมูลต้องการการสื่อสารช่องสัญญาณด้านข้างอย่างต่อเนื่องซึ่งใช้เวลาสล็อตที่มีค่า

  • อาจมีโอเวอร์เฮดโปรโตคอลเพิ่มเติมสำหรับอุปกรณ์จัดเก็บข้อมูลสำหรับไดรเวอร์อุปกรณ์หรือเลเยอร์ระบบไฟล์ (แพ็คเก็ตข้อมูลบรรจุ == ข้อมูลจัดเก็บ?)

คำถาม

  • ทำไมการใช้งานในปัจจุบันไม่สามารถสตรีมที่ 53 MB / s ได้?

  • คอขวดในการใช้งานในปัจจุบันอยู่ที่ไหน

และโอกาสในการติดตาม: ทำไมไม่มีใครพยายามกำจัดคอขวดเช่นนี้

อ้างอิง

[1] ข้อมูลจำเพาะ USB 2.0 อย่างเป็นทางการ

[2] มิเรอร์ pdf ด่วนของสเปค


2
คุณรู้หรือไม่ว่า USB 2.0 นั้นถูกแทนที่ด้วย USB 3.0 ซึ่งเร็วกว่าอย่างมากใช่ไหม?
JonnyBoats

8
จากความลึกของการวิจัยและความคุ้นเคยกับมาตรฐาน USB เป็นที่ชัดเจนว่า Chris คุ้นเคยกับ USB 3.0, @JonnyBoats
tyblu

5
@ JonnyBoats การตอบสนองอย่างยุติธรรมต่อสิ่งนี้คือ "คุณทราบหรือไม่ว่าคอมพิวเตอร์ส่วนใหญ่ยังคงมี USB2.0 และการอัปเดตมาตรฐานไม่ทำให้การอัปเกรดฮาร์ดแวร์ทั้งหมดเกิดขึ้นทันที" ฉันสงสัยว่ามันตั้งใจ แต่ความคิดเห็นที่คุณเขียนดูเหมือนจะเป็นการดูถูกในรูปแบบปัจจุบัน
Kortuk

Kortuk: ขอบคุณที่ชี้ให้เห็นว่าฉันไม่ได้ตั้งใจจะดูถูกใคร ประเด็นของฉันคือ USB นั้นเหมือนกับข้อมูลจำเพาะส่วนใหญ่วิวัฒนาการมาตามกาลเวลา 2.0 เร็วขึ้นจากนั้น 1.0 และ 3.0 กำลังเข้าสู่ตลาดและยังเร็วกว่า ฉันจะจินตนาการว่า บริษัท อื่น ๆ จะมุ่งเน้นไปที่การใช้ 3.0 แทนที่จะปรับปรุงที่ 2.0
JonnyBoats

1
ในขณะที่อาจมีที่ว่างสำหรับ 13 แพ็กเก็ตใน microframe ตัวควบคุมโฮสต์จำนวนมากไม่สามารถทำเช่นนั้นได้ ย้อนกลับไปในปี 2549 ส่วนใหญ่ถูก จำกัด ไว้ที่ 8 out และ 10 in - ฉันไม่รู้เลยว่ามันเปลี่ยนไปมากตั้งแต่นั้นมาหรือไม่
2793784

คำตอบ:


15

เมื่อถึงจุดหนึ่งในชีวิตของฉันฉันเคยทำธุรกิจ USB ให้กับ บริษัท กึ่งใหญ่ ผลลัพธ์ที่ดีที่สุดที่ฉันจำได้คือคอนโทรลเลอร์ NEC SATA สามารถผลักดันปริมาณข้อมูลจริงได้ 320Mbps สำหรับที่เก็บข้อมูลขนาดใหญ่อาจเป็นไดรฟ์ sata ปัจจุบันที่มีความสามารถนี้หรือมากกว่านั้นเล็กน้อย นี่คือการใช้ BOT (บางโปรโตคอลที่เก็บข้อมูลขนาดใหญ่ทำงานบน USB)

ฉันสามารถให้คำตอบโดยละเอียดทางเทคนิค แต่ฉันคิดว่าคุณสามารถอนุมานได้ สิ่งที่คุณต้องเห็นคือนี่คือระบบนิเวศเล่นการปรับปรุงที่สำคัญใด ๆ จะต้องมีใครบางคนเช่น Microsoft เพื่อเปลี่ยนสแต็กของพวกเขาเพิ่มประสิทธิภาพ ฯลฯ ซึ่งจะไม่เกิดขึ้น การทำงานร่วมกันนั้นสำคัญกว่าความเร็ว เนื่องจากสแต็คที่มีอยู่นั้นครอบคลุมความผิดพลาดของอุปกรณ์ที่นำออกใช้อย่างระมัดระวังเพราะเมื่อสเป็ค USB2 ออกมาน่าจะเป็นอุปกรณ์เริ่มต้นที่ไม่ได้ยืนยันสเป็กที่ดีตั้งแต่สเป็คเป็นรถ หากคุณสร้างระบบบริวโฮมโดยใช้ Linux หรือไดรเวอร์โฮสต์ USB แบบกำหนดเองสำหรับ MS และตัวควบคุมอุปกรณ์ที่รวดเร็วคุณอาจเข้าใกล้ขีด จำกัด ทางทฤษฎี

ในแง่ของการสตรีม ISO ควรจะเร็วมาก แต่ตัวควบคุมไม่สามารถใช้งานได้ดีมากเนื่องจาก 95% ของแอพใช้การถ่ายโอนจำนวนมาก

ในฐานะที่เป็นข้อมูลเชิงลึกเกี่ยวกับโบนัสตัวอย่างเช่นถ้าคุณไปและสร้างฮับไอซีในวันนี้ถ้าคุณทำตามข้อมูลจำเพาะของจุดคุณจะขายชิปเป็นศูนย์ หากคุณทราบข้อผิดพลาดทั้งหมดในตลาดและตรวจสอบให้แน่ใจว่า IC ศูนย์กลางของคุณสามารถทนต่อพวกเขาได้คุณอาจเข้าสู่ตลาดได้ ฉันยังคงประหลาดใจในวันนี้ USB ทำงานได้ดีแค่ไหนเพราะมีซอฟต์แวร์และชิปที่ไม่ดีพอ


6

นี่เป็นหัวข้อที่เก่ามาก แต่ยังไม่มีคำตอบ นี่คือความพยายามของฉัน:

ทำไมการใช้งานในปัจจุบันไม่สามารถสตรีมที่ 53 MB / s ได้?

การคำนวณค่อนข้างดี แต่คุณลืมบางสิ่งในจำนวนไบต์ที่มีอยู่ระหว่างตัวทำเครื่องหมายเฟรม:

  1. แต่ละ microframe มีสองเกณฑ์ที่เรียกว่า EOF1 และ EOF2 ไม่ต้องมีการเกิดกระแสไฟฟ้าบัสที่ / หลัง EOF1 ตำแหน่งของจุดนี้เป็นสิ่งที่ซับซ้อน แต่ตำแหน่งทั่วไปคือ 560 บิตครั้งก่อน SOF ถัดไป โฮสต์ต้องกำหนดเวลาการทำธุรกรรมในลักษณะที่การตอบสนองที่เป็นไปได้ใด ๆ จากช่องจะไม่ถึงขีด จำกัด ซึ่งกินประมาณ 70 ไบต์จาก 7487 ไบต์ที่คำนวณของคุณ

  2. คุณถือว่า "ข้อมูลสุ่ม" นี่คือไม่มีมูลความจริงอย่างสมบูรณ์ข้อมูลสามารถเป็นอะไรก็ได้ ดังนั้นโฮสต์จะต้องกำหนดเวลาการทำธุรกรรมสำหรับการบรรจุกรณีที่เลวร้ายที่สุดด้วยค่าใช้จ่ายในการบรรจุบิตสูงสุด 512 * 7/6 = ~ 600 ไบต์ บวกค่าใช้จ่ายในการทำธุรกรรม 24 ไบต์ตามที่คุณคำนวณอย่างถูกต้อง สิ่งนี้ให้ (7487-70) / 624 = 11.88 ธุรกรรมต่อไมโครเฟรม

  3. โฮสต์จำเป็นต้องสำรองแบนด์วิดท์ประมาณ 10% สำหรับธุรกรรมการควบคุมสำหรับกิจกรรมอื่น ๆ ดังนั้นเราจึงได้รับธุรกรรมประมาณ 10.7

  4. โฮสต์คอนโทรลเลอร์ยังมีเวลาแฝงที่แน่นอนเมื่อจัดการรายการที่ลิงก์ดังนั้นจึงมีช่องว่างเพิ่มเติมระหว่างธุรกรรม

  5. อุปกรณ์สามารถเป็น 5 ฮับ / ฮ็อปห่างไกลจากรูทและความล่าช้าในการตอบสนองอาจสูงถึง 1,700 ns ซึ่งกินอีก 106 ไบต์ของงบประมาณธุรกรรมแต่ละรายการ ในการประมาณการแบบดิบจะทำธุรกรรมเพียง 10.16 รายการต่อ uFrame ไม่นับแบนด์วิดท์ที่สงวนไว้

โฮสต์ไม่สามารถทำการปรับตารางเวลาใหม่ตามการมาถึงธุรกรรมจริงภายใน uFrame มันจะถูกห้ามจากมุมมองของซอฟต์แวร์ดังนั้นไดรเวอร์ใช้ตารางเวลาที่อนุรักษ์นิยมมากที่สุดมากถึง 9 ธุรกรรมขนาดใหญ่ต่อ uFrame ซึ่งมีจำนวน 36 Mbytes / ที่สอง นี่คือสิ่งที่ไดรฟ์ปากกา USB ที่ดีมากสามารถให้ได้

มาตรฐานการประดิษฐ์ที่บ้าคลั่งบางรายการสามารถทำธุรกรรมได้ถึง 11 รายการต่อ uFrame ซึ่งทำให้มีขนาด 44 MBps และนี่คือค่าสูงสุดสำหรับโปรโตคอล HS USB

คอขวดในการใช้งานในปัจจุบันอยู่ที่ไหน

อย่างที่เราเห็นด้านบนไม่มีบอทคอลพื้นที่บิตบิตแบบดิบทั้งหมดถูกกินโดยค่าใช้จ่ายในโพรโทคอล

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.