Tại sao các thiết bị USB chậm hơn 480 MBit / s


41

Động lực

Với tốc độ tín hiệu là 480 MBit / s, các thiết bị USB 2.0 sẽ có thể truyền dữ liệu với tốc độ lên tới 60 MB / s. Tuy nhiên, các thiết bị ngày nay dường như bị giới hạn ở mức 30-42 MB / s trong khi đọc [ Wiki: USB ]. Đó là một chi phí 30 phần trăm.

USB 2.0 là một tiêu chuẩn thực tế cho các thiết bị bên ngoài trong hơn 10 năm. Một trong những ứng dụng quan trọng nhất cho giao diện USB từ rất sớm là lưu trữ di động. Thật không may, USB 2.0 đã nhanh chóng hạn chế tốc độ tắc nghẽn đối với các ứng dụng đòi hỏi băng thông này, một ổ cứng ngày nay chẳng hạn có khả năng hơn 90 MB / giây khi đọc tuần tự. Xem xét sự hiện diện của thị trường lâu dài và nhu cầu liên tục về băng thông cao hơn, chúng ta nên kỳ vọng rằng hệ sinh thái USB 2.0 đã được tối ưu hóa qua nhiều năm và đạt được hiệu suất đọc gần với giới hạn lý thuyết.

Băng thông tối đa lý thuyết trong trường hợp của chúng tôi là gì? Mọi giao thức đều có phí bao gồm cả USB và theo tiêu chuẩn USB 2.0 chính thức, nó là 53.248 MB / s [ 2 , Bảng 5-10]. Điều đó có nghĩa là về mặt lý thuyết , các thiết bị USB 2.0 ngày nay có thể nhanh hơn 25%.

Phân tích

Để đến bất cứ nơi nào gần gốc rễ của vấn đề này, phân tích sau đây sẽ cho thấy những gì đang xảy ra trên xe buýt trong khi đọc dữ liệu tuần tự từ một thiết bị lưu trữ. Giao thức được chia nhỏ từng lớp và chúng tôi đặc biệt quan tâm đến câu hỏi tại sao 53.248 MB / s là số lý thuyết tối đa cho các thiết bị ngược dòng số lượng lớn. Cuối cùng, chúng tôi sẽ nói về các giới hạn của phân tích có thể cung cấp cho chúng tôi một số gợi ý về chi phí bổ sung.

Ghi chú

Trong suốt câu hỏi này, chỉ có tiền tố thập phân được sử dụng.

Máy chủ lưu trữ USB 2.0 có khả năng xử lý nhiều thiết bị (thông qua trung tâm) và nhiều điểm cuối trên mỗi thiết bị. Điểm cuối có thể hoạt động trong các chế độ chuyển khác nhau. Chúng tôi sẽ giới hạn phân tích của chúng tôi ở một thiết bị duy nhất được gắn trực tiếp vào máy chủ và có khả năng liên tục gửi các gói đầy đủ qua điểm cuối hàng loạt ngược dòng ở chế độ Tốc độ cao.

Đóng khung

Giao tiếp tốc độ cao USB được đồng bộ hóa trong một cấu trúc khung cố định. Mỗi khung hình dài 125 chúng tôi và bắt đầu bằng gói Start-Of-Frame (SOF) và bị giới hạn bởi và chuỗi End-Of-Frame (EOF). Mỗi gói bắt đầu bằng SYNC và kết thúc bằng và End-Of-Packet (EOF). Những trình tự đã được thêm vào sơ đồ cho rõ ràng. EOP có thể thay đổi kích thước và dữ liệu gói, đối với SOF, nó luôn là 5 byte.

nhập mô tả hình ảnh ở đây Mở hình ảnh trong một tab mới để xem phiên bản lớn hơn.

Giao dịch

USB là một giao thức điều khiển chính và mỗi giao dịch được bắt đầu bởi máy chủ. Thời gian giữa SOF và EOF có thể được sử dụng cho các giao dịch USB. Tuy nhiên, thời gian cho SOF và EOF rất nghiêm ngặt và máy chủ chỉ bắt đầu các giao dịch có thể hoàn thành đầy đủ trong khoảng thời gian miễn phí.

Giao dịch chúng tôi quan tâm là một giao dịch IN số lượng lớn thành công. Giao dịch bắt đầu với gói mã thông báo IN, sau đó máy chủ chờ gói dữ liệu DATA0 / DATA1 và xác nhận việc truyền bằng gói bắt tay ACK. EOP cho tất cả các gói này là 1 đến 8 bit tùy thuộc vào dữ liệu gói, chúng tôi giả sử trường hợp xấu nhất ở đây.

Giữa mỗi ba gói này, chúng tôi phải xem xét thời gian chờ đợi. Chúng nằm giữa bit cuối cùng của gói IN từ máy chủ và bit đầu tiên của gói DATA0 của thiết bị và giữa bit cuối cùng của gói DATA0 và bit đầu tiên của gói ACK. Chúng tôi không phải xem xét bất kỳ sự chậm trễ nào nữa vì máy chủ có thể bắt đầu gửi IN tiếp theo ngay sau khi gửi ACK. Thời gian truyền cáp được xác định là tối đa 18 ns.

Chuyển khoản số lượng lớn có thể gửi tối đa 512 byte cho mỗi giao dịch IN. Và máy chủ lưu trữ sẽ cố gắng phát hành càng nhiều giao dịch càng tốt ở giữa các dấu phân cách khung. Mặc dù chuyển số lượng lớn có mức độ ưu tiên thấp nhưng nó có thể chiếm hết thời gian có sẵn trong một vị trí khi không có giao dịch nào khác đang chờ xử lý.

Để đảm bảo phục hồi đồng hồ đúng, các tiêu chuẩn xác định phương thức nhồi bit gọi. Khi gói sẽ yêu cầu một chuỗi rất dài của cùng một đầu ra, một sườn bổ sung được thêm vào. Điều đó đảm bảo sườn sau tối đa 6 bit. Trong trường hợp xấu nhất, điều này sẽ làm tăng tổng kích thước gói lên 7/6. EOP không bị nhồi bit.

nhập mô tả hình ảnh ở đây Mở hình ảnh trong một tab mới để xem phiên bản lớn hơn.

Tính toán băng thông

Một giao dịch IN số lượng lớn có tổng phí là 24 byte và tải trọng 512 byte. Đó là tổng cộng 536 byte. Khoảng thời gian giữa là 7487 byte. Không cần nhồi bit, có không gian cho 13.968 gói. Có 8000 Micro-Frames mỗi giây, chúng ta có thể đọc dữ liệu với 13 * 512 * 8000 B / s = 53.248 MB / s

Đối với dữ liệu hoàn toàn ngẫu nhiên, chúng tôi hy vọng rằng việc nhồi bit là cần thiết ở một trong 2 ** 6 = 64 chuỗi 6 bit liên tiếp. Đó là mức tăng của (63 * 6 + 7) / (64 * 6). Nhân tất cả các byte có thể bị nhồi bit bởi các số đó sẽ cho tổng thời lượng giao dịch là (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537,38 Byte. Kết quả là có 13.932 gói trên mỗi Micro-Frame.

Có một trường hợp đặc biệt khác bị thiếu trong các tính toán này. Tiêu chuẩn xác định thời gian đáp ứng thiết bị tối đa là 192 bit lần [ 2 , Chương 7.1.19.2]. Điều này phải được xem xét khi quyết định nếu gói cuối cùng vẫn phù hợp với khung trong trường hợp thiết bị cần thời gian đáp ứng đầy đủ. Chúng ta có thể giải thích điều đó bằng cách sử dụng một cửa sổ 7439 byte. Băng thông kết quả là giống hệt nhau.

Những gì còn lại

  • Phát hiện lỗi và phục hồi chưa được bảo hiểm. Có thể lỗi là đủ thường xuyên hoặc phục hồi lỗi là tốn thời gian đủ để có tác động đến hiệu suất trung bình.

  • Chúng tôi đã giả định phản ứng máy chủ và thiết bị ngay lập tức sau các gói và giao dịch. Cá nhân tôi không thấy bất kỳ nhu cầu xử lý lớn nào ở cuối gói hoặc giao dịch ở hai bên và do đó tôi không thể nghĩ ra bất kỳ lý do nào khiến máy chủ hoặc thiết bị không thể đáp ứng ngay lập tức với việc triển khai phần cứng được tối ưu hóa đầy đủ. Đặc biệt trong hoạt động bình thường, hầu hết các công việc giữ sách và phát hiện lỗi có thể được thực hiện trong quá trình giao dịch và các gói và giao dịch tiếp theo có thể được xếp hàng.

  • Chuyển cho các điểm cuối khác hoặc giao tiếp bổ sung đã không được xem xét. Có thể giao thức chuẩn cho các thiết bị lưu trữ yêu cầu một số giao tiếp kênh bên liên tục tiêu tốn thời gian khe có giá trị.

  • Có thể có một giao thức bổ sung cho các thiết bị lưu trữ cho trình điều khiển thiết bị hoặc lớp hệ thống tệp. (tải trọng gói == dữ liệu lưu trữ?)

Câu hỏi

  • Tại sao các triển khai ngày nay không có khả năng phát trực tuyến ở mức 53 MB / s?

  • Đâu là nút thắt trong việc triển khai ngày nay?

Và một tiềm năng tiếp theo: Tại sao không ai cố gắng loại bỏ nút thắt như vậy?

Người giới thiệu

[1] Thông số kỹ thuật USB 2.0 chính thức

[2] Gương pdf nhanh của đặc điểm kỹ thuật


2
Bạn có biết rằng USB 2.0 đã được thay thế bởi USB 3.0 nhanh hơn đáng kể không?
JonnyBoats

8
Từ chiều sâu nghiên cứu và sự quen thuộc rõ ràng với tiêu chuẩn USB, rõ ràng Chris đã quen thuộc với USB 3.0, @JonnyBoats.
tyblu

5
@JonnyBoats, câu trả lời công bằng cho điều đó sẽ là, "Bạn có biết rằng hầu hết các máy tính vẫn có USB2.0 và bản cập nhật tiêu chuẩn không làm cho tất cả các nâng cấp phần cứng xảy ra ngay lập tức?" Tôi nghi ngờ nó đã được dự định nhưng bình luận bạn đã viết có vẻ hơi xúc phạm trong hình thức hiện tại của nó.
Kortuk

Kortuk: Cảm ơn vì đã chỉ ra điều đó, chắc chắn tôi không có ý định xúc phạm bất cứ ai. Quan điểm của tôi là USB, giống như hầu hết các thông số kỹ thuật, phát triển theo thời gian. 2.0 nhanh hơn 1.0 và 3.0 hiện đang có mặt trên thị trường và vẫn nhanh hơn. Tôi sẽ tưởng tượng nhiều công ty sẽ tập trung vào việc áp dụng 3.0 hơn là cải thiện trên 2.0
JonnyBoats

1
Mặc dù có thể có không gian cho 13 gói trong microframe, nhiều bộ điều khiển máy chủ thực sự không thể làm điều đó. Quay trở lại năm 2006, hầu hết chỉ giới hạn ở 8 và 10 in - Tôi không biết điều đó có thay đổi nhiều hay không.
dùng2793784

Câu trả lời:


15

Vào một số thời điểm trong cuộc đời, tôi từng điều hành việc kinh doanh USB cho một công ty bán lớn. Kết quả tốt nhất mà tôi nhớ là bộ điều khiển NEC SATA có khả năng đẩy thông lượng dữ liệu thực tế 320Mbps để lưu trữ dung lượng lớn, có lẽ các ổ đĩa sata hiện tại có khả năng này hoặc hơn một chút. Điều này đã sử dụng BOT (một số giao thức lưu trữ lớn chạy trên USB).

Tôi có thể đưa ra một câu trả lời chi tiết về kỹ thuật nhưng tôi đoán bạn có thể tự suy luận. Những gì bạn cần thấy là, đây là trò chơi hệ sinh thái, bất kỳ cải tiến đáng kể nào cũng sẽ yêu cầu ai đó như Microsoft thay đổi ngăn xếp của họ, tối ưu hóa, v.v., điều này sẽ không xảy ra. Khả năng tương tác quan trọng hơn nhiều so với tốc độ. Bởi vì các ngăn xếp hiện có cẩn thận khắc phục các lỗi của hàng loạt thiết bị ngoài kia vì khi thông số kỹ thuật USB2 xuất hiện có lẽ các thiết bị ban đầu không thực sự xác nhận với thông số kỹ thuật đó vì thông số kỹ thuật đã bị lỗi, v.v. Nếu bạn xây dựng một hệ thống sản xuất bia tại nhà bằng Linux hoặc trình điều khiển máy chủ USB tùy chỉnh cho MS và bộ điều khiển thiết bị nhanh, bạn có thể có thể tiến gần đến giới hạn lý thuyết.

Về mặt phát trực tuyến, ISO được cho là rất nhanh nhưng bộ điều khiển không thực hiện tốt điều đó, vì 95% ứng dụng sử dụng Chuyển khoản số lượng lớn.

Như một cái nhìn sâu sắc về phần thưởng, ví dụ, nếu bạn đi và xây dựng một IC trung tâm ngày hôm nay, nếu bạn làm theo thông số kỹ thuật cho dấu chấm, thực tế bạn sẽ bán chip không. Nếu bạn biết tất cả các lỗi trên thị trường và đảm bảo IC trung tâm của bạn có thể chịu đựng được chúng, bạn có thể tham gia vào thị trường. Hôm nay tôi vẫn còn ngạc nhiên, USB hoạt động tốt như thế nào với số lượng phần mềm và chip xấu hiện có.


6

Đây là một chủ đề rất cũ, nhưng nó chưa có câu trả lời. Đây là nỗ lực của tôi:

Tại sao các triển khai ngày nay không có khả năng phát trực tuyến ở mức 53 MB / s?

Các tính toán gần như tốt, nhưng bạn đang quên một vài điều trong số byte có sẵn giữa các điểm đánh dấu khung:

  1. Mỗi microframe có hai ngưỡng được gọi là EOF1 và EOF2. Không có hoạt động xe buýt phải xảy ra tại / sau EOF1. Vị trí của điểm này là một điều phức tạp, nhưng vị trí điển hình là 560 bit lần trước SOF tiếp theo. Một máy chủ lưu trữ phải lên lịch các giao dịch của mình theo cách mà bất kỳ phản hồi nào có thể có từ kênh sẽ không đạt đến ngưỡng này. Mà ăn khoảng 70 byte trong số 7487 byte được tính toán của bạn.

  2. Bạn giả sử "dữ liệu ngẫu nhiên". Điều này là hoàn toàn không có cơ sở, dữ liệu có thể là bất cứ điều gì. Do đó, máy chủ phải lên lịch giao dịch cho tải trọng trong trường hợp xấu nhất, với chi phí nhồi bit tối đa, 512 * 7/6 = ~ 600 byte. Cộng thêm 24 byte phí giao dịch, như bạn đã tính đúng. Điều này mang lại (7487-70) / 624 = 11,88 giao dịch trên mỗi khung vi mô.

  3. Máy chủ được yêu cầu dự trữ khoảng 10% băng thông cho các giao dịch kiểm soát cho bất kỳ hoạt động nào khác, vì vậy chúng tôi nhận được khoảng 10,7 giao dịch.

  4. Bộ điều khiển máy chủ cũng có độ trễ nhất định khi quản lý danh sách được liên kết của nó, do đó có thêm khoảng cách giữa các giao dịch.

  5. Thiết bị có thể là 5 hub / hops cách xa gốc và độ trễ phản hồi có thể lên tới 1700 ns, ăn thêm 106 byte cho mỗi ngân sách giao dịch. Trong ước tính thô, nó chỉ thực hiện 10,16 giao dịch trên mỗi uFrame, không tính băng thông dành riêng.

Máy chủ không thể lập lịch lại thích ứng dựa trên giao dịch thực tế trong uFrame, điều này sẽ bị cấm từ góc độ phần mềm, vì vậy, trình điều khiển sử dụng lịch biểu bảo thủ nhất, tối đa 9 giao dịch hàng loạt trên mỗi uFrame, lên tới 36 Mbyte / thứ hai. Đây là những gì một ổ đĩa bút USB rất tốt có thể cung cấp.

Một số điểm chuẩn nhân tạo điên rồ có thể lên tới 11 giao dịch trên mỗi uFrame, khiến cho nó đạt 44 MBps. Và đây là mức tối đa tuyệt đối cho giao thức USB HS.

Đâu là nút thắt trong việc triển khai ngày nay?

Như người ta có thể thấy ở trên, không có botleneck, tất cả không gian thời gian bit thô được ăn bởi giao thức.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.