동기

480MBit / s의 신호 전송률로 USB 2.0 장치는 최대 60MB / s의 데이터를 전송할 수 있어야합니다. 그러나 오늘날의 장치는 [ Wiki : USB ] 를 읽는 동안 30-42MB / s로 제한되는 것 같습니다 . 이는 30 %의 오버 헤드입니다.

USB 2.0은 10 년 이상 외부 장치의 사실상 표준이었습니다. 초기부터 USB 인터페이스를위한 가장 중요한 응용 프로그램 중 하나는 휴대용 저장소였습니다. 불행히도 USB 2.0은 이러한 대역폭을 요구하는 응용 프로그램의 병목 현상을 신속하게 제한하는 병목 현상이었습니다. 오늘날의 HDD는 예를 들어 90MB / s 이상을 순차적으로 읽을 수 있습니다. 오랜 시장 존재와 더 높은 대역폭에 대한 지속적인 요구를 고려할 때 USB 2.0 에코 시스템은 수년에 걸쳐 최적화되었으며 이론적 인 한계에 가까운 읽기 성능에 도달했을 것으로 예상됩니다.

우리의 경우 이론상 최대 대역폭은 얼마입니까? 모든 프로토콜에는 USB를 포함한 오버 헤드가 있으며 공식 USB 2.0 표준에 따르면 53.248MB / s입니다 [ 2 , 표 5-10]. 이론적으로 오늘날의 USB 2.0 장치는 25 % 더 빠를 수 있습니다.

분석

이 문제의 근본에 가까운 곳으로 가려면 다음 분석에서 스토리지 장치에서 순차 데이터를 읽는 동안 버스에서 발생하는 상황을 보여줍니다. 이 프로토콜은 계층별로 분류되어 있으며 특히 대량 업스트림 장치의 최대 이론적 수인 53.248MB / s에 대한 질문에 관심이 있습니다. 마지막으로 분석의 한계에 대해 이야기하고 추가 오버 헤드에 대한 힌트를 줄 것입니다.

노트

이 질문 전체에서 소수 접두사 만 사용됩니다.

USB 2.0 호스트는 장치 당 여러 장치 (허브를 통해) 및 여러 끝점을 처리 할 수 ​​있습니다. 엔드 포인트는 다른 전송 모드에서 작동 할 수 있습니다. 분석을 호스트에 직접 연결되어 고속 모드에서 업스트림 벌크 엔드 포인트를 통해 전체 패킷을 지속적으로 전송할 수있는 단일 장치로 분석을 제한합니다.

프레이밍

USB 고속 통신은 고정 프레임 구조로 동기화됩니다. 각 프레임의 길이는 125 us이며 프레임 시작 패킷 (SOF)으로 시작하며 프레임 끝 시퀀스 (EOF)에 의해 제한됩니다. 각 패킷은 SYNC로 시작하고 EOF (End-Of-Packet)로 끝납니다. 이러한 시퀀스는 명확성을 위해 다이어그램에 추가되었습니다. EOP는 크기 및 패킷 데이터에 따라 달라지며 SOF의 경우 항상 5 바이트입니다.

더 큰 버전을 보려면 새 탭에서 이미지를여십시오.

업무

USB는 마스터 기반 프로토콜이며 각 트랜잭션은 호스트에 의해 시작됩니다. SOF와 EOF 사이의 타임 슬롯은 USB 트랜잭션에 사용될 수 있습니다. 그러나 SOF 및 EOF 타이밍은 매우 엄격하며 호스트는 사용 가능한 시간 슬롯 내에서 완전히 완료 될 수있는 트랜잭션 만 시작합니다.

우리가 관심있는 거래는 성공적인 대량 거래입니다. 트랜잭션은 토큰 패킷 IN으로 시작한 다음 호스트가 데이터 패킷 DATA0 / DATA1을 기다린 후 핸드 셰이크 패킷 ACK로 전송을 확인합니다. 이 모든 패킷의 EOP는 패킷 데이터에 따라 1에서 8 비트이며 여기서 최악의 경우를 가정했습니다.

이 세 패킷 각각 사이에서 대기 시간을 고려해야합니다. 이들은 호스트로부터의 IN 패킷의 마지막 비트와 장치의 DATA0 패킷의 첫 번째 비트 사이 및 DATA0 패킷의 마지막 비트와 ACK 패킷의 첫 번째 비트 사이에있다. 호스트가 ACK를 보낸 직후 다음 IN을 보내기 시작할 수 있으므로 더 이상 지연을 고려할 필요가 없습니다. 케이블 전송 시간은 최대 18ns로 정의됩니다.

대량 전송은 IN 트랜잭션 당 최대 512 바이트를 보낼 수 있습니다. 그리고 호스트는 프레임 구분 기호 사이에서 가능한 한 많은 트랜잭션을 발행하려고 시도합니다. 대량 전송의 우선 순위는 낮지 만 보류중인 다른 트랜잭션이없는 경우 슬롯에서 사용 가능한 모든 시간을 차지할 수 있습니다.

적절한 클럭 복구를 보장하기 위해 표준은 메소드 호출 비트 스터핑을 정의합니다. 패킷이 매우 긴 동일한 출력 시퀀스를 요구할 때 추가 측면이 추가됩니다. 최대 6 비트 후 측면을 보장합니다. 최악의 경우 총 패킷 크기가 7/6 증가합니다. EOP에는 비트 스터핑이 적용되지 않습니다.

더 큰 버전을 보려면 새 탭에서 이미지를여십시오.

대역폭 계산

대량 IN 트랜잭션의 오버 헤드는 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 바이트입니다. 결과적으로 Micro-Frame 당 13.932 개의 패킷이 생성됩니다.

이 계산에서 누락 된 또 다른 특별한 경우가 있습니다. 표준은 192 비트 시간의 최대 장치 응답 시간을 정의합니다 [ 2 , 장 7.1.19.2]. 장치가 전체 응답 시간을 필요로하는 경우 마지막 패키지가 여전히 프레임에 맞는지 여부를 결정할 때이 점을 고려해야합니다. 우리는 7439 바이트의 창을 사용하여이를 설명 할 수 있습니다. 결과 대역폭은 동일합니다.

남은 것

• 오류 감지 및 복구는 다루지 않았습니다. 오류가 자주 발생하거나 오류 복구가 평균 성능에 영향을 줄만큼 시간이 오래 걸릴 수 있습니다.

• 우리는 패킷과 트랜잭션 후 즉각적인 호스트 및 장치 반응을 가정했습니다. 개인적으로 어느 쪽의 패킷이나 트랜잭션이 끝날 때 큰 처리 작업이 필요하지 않으므로 호스트 또는 장치가 충분히 최적화 된 하드웨어 구현으로 즉시 응답 할 수없는 이유를 생각할 수 없습니다. 특히 정상적인 작동에서는 대부분의 장부 유지 및 오류 감지 작업이 트랜잭션 중에 수행 될 수 있으며 다음 패킷 및 트랜잭션이 대기 될 수 있습니다.

• 다른 엔드 포인트에 대한 전송 또는 추가 통신은 고려되지 않았습니다. 스토리지 장치의 표준 프로토콜은 귀중한 슬롯 시간을 소비하는 연속적인 사이드 채널 통신이 필요할 수 있습니다.

• 장치 드라이버 또는 파일 시스템 계층의 저장 장치에 대한 추가 프로토콜 오버 헤드가있을 수 있습니다. (패킷 페이로드 == 스토리지 데이터?)

질문

• 오늘날 구현에서 53MB / s로 스트리밍 할 수없는 이유는 무엇입니까?

• 오늘날 구현에서 병목 현상은 어디에 있습니까?

그리고 잠재적 인 후속 조치 : 왜 아무도 그러한 병목 현상을 제거하려고하지 않았습니까?

참고 문헌

[1] 공식 USB 2.0 사양

[2] 사양의 빠른 pdf 거울

제 인생의 어느 시점에서 저는 대기업의 USB 사업을 운영했습니다. 내가 기억하는 가장 좋은 결과는 대용량 저장 장치에 320Mbps의 실제 데이터 처리량을 제공 할 수있는 NEC SATA 컨트롤러였으며 현재 SATA 드라이브가 이보다 약간 더 많은 성능을 제공 할 수 있습니다. 이것은 BOT (일부 대용량 스토리지 프로토콜은 USB에서 실행 됨)를 사용하고있었습니다.

기술적 세부 답변을 줄 수는 있지만 스스로 추론 할 수있을 것 같습니다. 당신이보아야 할 것은 이것이 생태계 재생이며, 중요한 개선을 위해서는 Microsoft와 같은 누군가가 스택을 변경하고 최적화하는 등의 일이 필요하지 않을 것입니다. 상호 운용성은 속도보다 훨씬 중요합니다. 기존 스택은 USB2 사양이 나오면 초기 사양이 사양에 버그가 있기 때문에 사양에 버그가 있는지 인증 시스템이 버그 등을 확인하지 않았기 때문에 많은 장치의 실수를 조심스럽게 다루기 때문입니다. Linux 및 MS 용 USB 호스트 드라이버 및 빠른 장치 컨트롤러를 사용하여자가 추출 시스템을 구축하는 경우 이론적 인 한계에 근접 할 수 있습니다.

스트리밍 측면에서 ISO는 매우 빠르지 만 컨트롤러의 95 %가 대량 전송을 사용하기 때문에 컨트롤러가이를 잘 구현하지 못합니다.

예를 들어, 오늘날 허브 IC를 구축하고 사양을 따르면 실제로 제로 칩을 판매 할 수 있습니다. 시장의 모든 버그를 알고 허브 IC가이를 견딜 수 있는지 확인하면 시장에 진입 할 수 있습니다. 나는 오늘도 여전히 놀랍습니다. USB가 얼마나 많은 나쁜 소프트웨어와 칩을 제공하는지 잘 알고 있습니다.

이것은 매우 오래된 주제이지만 아직 답이 없습니다. 이것은 나의 시도이다 :

오늘날 구현에서 53MB / s로 스트리밍 할 수없는 이유는 무엇입니까?

계산은 거의 가능하지만 프레임 마커 사이의 사용 가능한 바이트 수에서 몇 가지 사항을 잊고 있습니다.

1. 각 마이크로 프레임에는 EOF1 및 EOF2라는 두 개의 임계 값이 있습니다. EOF1 이후에는 버스 활동이 없어야합니다. 이 지점을 배치하는 것은 복잡한 일이지만 일반적인 위치는 다음 SOF보다 560 비트입니다. 호스트는 채널의 응답이이 임계 값에 도달하지 않도록 트랜잭션을 예약해야합니다. 계산 된 7487 바이트 중에서 약 70 바이트를 먹는다.

2. "무작위 데이터"라고 가정합니다. 이것은 완전히 근거가 없으며 데이터는 무엇이든 될 수 있습니다. 따라서 호스트는 최대 비트 스터핑 오버 헤드가 512 * 7 / 6 = ~ 600 바이트 인 최악의 페이로드에 대한 트랜잭션을 예약해야합니다. 올바르게 계산 한대로 24 바이트의 트랜잭션 오버 헤드가 추가되었습니다. 이것은 마이크로 프레임 당 (7487-70) / 624 = 11.88 트랜잭션을 제공합니다.

3. 호스트는 다른 활동에 대한 제어 트랜잭션을 위해 약 10 %의 대역폭을 예약해야하므로 약 10.7 트랜잭션을 얻습니다.

4. 호스트 컨트롤러는 또한 연결된 목록을 관리 할 때 특정 대기 시간이 있으므로 트랜잭션간에 추가 간격이 있습니다.

5. 장치는 루트에서 멀리 떨어진 5 개의 허브 / 홉이 될 수 있으며 응답 지연은 최대 1700ns가 될 수 있으며 각 트랜잭션 예산의 106 바이트를 더 소비합니다. 원시 추정에서는 예약 된 대역폭을 계산하지 않고 uFrame 당 10.16 개의 트랜잭션 만 만듭니다.

호스트는 uFrame 내에서 실제 트랜잭션 도착을 기반으로 적응 형 재 예약을 수행 할 수 없으므로 소프트웨어 관점에서는 엄청나므로 드라이버는 uFrame 당 최대 9 개의 대량 트랜잭션 (최대 36MB)으로 가장 보수적 인 일정을 사용합니다. 둘째. 이것이 아주 좋은 USB 펜 드라이브가 제공 할 수있는 것입니다.

일부 미친 인공 벤치 마크는 uFrame 당 최대 11 개의 트랜잭션을 처리 할 수 ​​있으므로 44MBps가됩니다. 그리고 이것은 HS USB 프로토콜의 절대 최대 값입니다.

오늘날 구현에서 병목 현상은 어디에 있습니까?

위에서 볼 수 있듯이, 병목 현상이 없으며 모든 원시 비트 타임 공간은 프로토콜 오버 헤드로 먹습니다.