แรงจูงใจ
ด้วยอัตราการส่งสัญญาณ 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 ได้?
คอขวดในการใช้งานในปัจจุบันอยู่ที่ไหน
และโอกาสในการติดตาม: ทำไมไม่มีใครพยายามกำจัดคอขวดเช่นนี้