为什么 USB 设备的速度低于 480 MBit/s

电器工程 USB 沟通 司机 协议 带宽
2021-12-31 03:18:43

动机

信号速率为 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 生态系统经过多年优化，并达到接近理论极限的读取性能。

在我们的案例中，理论上的最大带宽是多少？每个协议都有开销，包括 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 开头，并以 End-Of-Packet (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 的数据

对于完全随机的数据，我们预计在 2**6 = 64 个 6 个连续位的序列之一中需要进行位填充。这增加了 (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镜像

2个回答

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

我可以给出一个技术上的详细答案，但我想你可以自己推断。你需要看到的是，这是生态系统的游戏，任何重大的改进都需要像微软这样的人来改变他们的堆栈、优化等，这是不会发生的。互操作性远比速度重要。因为现有的堆栈仔细地掩盖了大量设备的错误，因为当 USB2 规范出来时，最初的设备可能并没有真正确认规范，因为规范有问题，认证系统有问题等等。如果您使用 Linux 或用于 MS 的自定义 USB 主机驱动程序和快速设备控制器构建家庭 brew 系统，您可能会接近理论极限。

在流传输方面，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 协议的绝对最大值。

当今实现的瓶颈在哪里？

正如上面所见，没有瓶颈，所有原始位时间空间都被协议开销吃掉了。

其它你可能感兴趣的问题
上一篇LED的延迟是多少？ 下一篇启用 CAN 的微控制器是否足以驱动 CAN 总线？