动机

信号速率为480 MBit / s时，USB 2.0设备应能够以高达60 MB / s的速度传输数据。但是，今天的设备在阅读[ Wiki：USB ]时似乎被限制为30-42 MB / s 。那是30％的开销。

十多年来，USB 2.0已经成为外部设备的事实上的标准。早期以来，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，并以帧起始数据包（SOF）开始，并受帧结束序列（EOF）限制。每个数据包均以SYNC开头，并以和数据包结尾（EOF）结尾。为了清楚起见，这些序列已添加到图中。EOP的大小是可变的，并且取决于分组数据，对于SOF，它始终为5个字节。

在新标签页中打开图片可查看大图。

交易次数

USB是主驱动协议，每个事务都由主机启动。SOF和EOF之间的时隙可用于USB事务。但是，SOF和EOF的时间安排非常严格，并且主机仅启动可以在空闲时隙内完全完成的事务。

我们感兴趣的事务是成功的批量IN事务。事务从令牌包IN开始，然后主机等待数据包DATA0 / DATA1，并通过握手包ACK确认传输。所有这些数据包的EOP都是1到8位，具体取决于数据包数据，在此我们假定了最坏的情况。

在这三个数据包之间，我们必须考虑等待时间。它们位于主机的IN数据包的最后一位与设备的DATA0数据包的首位之间，以及DATA0数据包的最后一位与ACK数据包的第一位之间。我们不必考虑任何进一步的延迟，因为主机可以在发送ACK之后立即开始发送下一个IN。电缆传输时间定义为最大18 ns。

批量传输每个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字节。每个微帧产生13.932数据包。

这些计算还缺少另一个特殊情况。该标准定义了最大设备响应时间为192位时间[ 2，第7.1.19.2章]。在确定最后一个包装是否仍然适合框架时，必须考虑到这一点，以防设备需要完整的响应时间。我们可以通过使用7439字节的窗口来解决这个问题。虽然结果带宽是相同的。

还剩什么

• 错误检测和恢复尚未涵盖。错误可能足够频繁，或者错误恢复很耗时，从而影响平均性能。

• 我们假设数据包和事务处理后，主机和设备会立即做出反应。我个人认为在任一端的数据包或事务结束时都不需要进行大的处理任务，因此，我无法想到主机或设备不能通过充分优化的硬件实现立即做出响应的任何原因。特别是在正常操作中，大多数记账和错误检测工作都可以在交易期间完成，并且下一个数据包和交易可以排队。

• 没有考虑其他端点的传输或其他通信。也许用于存储设备的标准协议需要一些连续的边信道通信，这会浪费宝贵的时隙时间。

• 设备驱动程序或文件系统层的存储设备可能会有额外的协议开销。（数据包有效载荷==存储数据？）

题

• 为什么今天的实现无法以53 MB / s的速度进行流传输？

• 当今实施的瓶颈在哪里？

以及可能的跟进：为什么没有人试图消除这种瓶颈？

参考文献

[1] 官方USB 2.0规范

[2] 规格的快速pdf镜像

在我生命中的某个时候，我曾经为一家大型半导体公司经营USB业务。我记得最好的结果是NEC SATA控制器能够推动320Mbps的实际数据吞吐量以进行大容量存储，可能当前的sata驱动器能够达到或略有提高。这是使用BOT（某些大容量存储协议在USB上运行）。

我可以提供详细的技术解答，但我想您可以推论自己。您需要看到的是，这是生态系统的发挥，任何重大改进都将需要像Microsoft这样的人来更改其堆栈，进行优化等，而这不会发生。互操作性远比速度重要。因为现有的堆栈仔细地掩盖了许多设备的错误，因为当USB2规范问世时，最初的设备可能并没有真正确认该规范，因为该规范存在缺陷，认证系统存在缺陷等等。如果您使用Linux或用于MS的自定义USB主机驱动程序以及快速的设备控制器构建家庭酿造系统，则可能会接近理论极限。

就流而言，ISO应该很快，但是控制器却不能很好地实现，因为95％的应用程序都使用批量传输。

例如，如果您今天就去构建集线器IC，则遵循一个规范，便可以得出实际上有零芯片的销售。如果您知道市场上的所有错误，并确保您的集线器IC能够容忍这些错误，那么您就可以进入市场。今天，我仍然感到惊讶，考虑到那里存在许多不良软件和芯片，USB的运行状况如何。

这是一个非常古老的话题，但是还没有答案。这是我的尝试：

为什么今天的实现无法以53 MB / 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个集线器/跃点，并且响应延迟可以高达1700 ns，这将占用每个事务预算的另外106个字节。原始估算中，每个uFrame仅进行10.16个事务，不包括保留的带宽。

主机无法基于uFrame内的实际事务到达来进行自适应重新调度，从软件角度来看这是禁止的，因此驱动程序使用最保守的调度，每个uFrame最多进行9笔大事务，总计36 Mbytes /第二。这是一个非常好的USB笔式驱动器可以提供的功能。

某些疯狂的人工基准测试可以使每个uFrame最多进行11个事务，这使其达到44 MBps。这是HS USB协议的绝对最大值。

当今实施的瓶颈在哪里？

从上面可以看到，没有瓶颈，协议开销消耗了所有原始位时间空间。