|
在嵌入式系统中有两种最常见互连：以太网和RapidIO。在本文的上半部分我们分析了这两种互连技术的发展现状，在逻辑层、包格式、无损传输以及市场应用方面对两种技术进行了比较，在下半部分我们将在吞吐量、延迟和流控方面进行对比。 吞吐量、延迟和流控 延迟，具体说是传输延迟，可以通过增加带宽得到改善。以太网和RapidIO技术在线速率增加时，传输延迟改善得到了体现。 传输延迟只是一个结构中整体延迟的一部分。整体延迟包括发送包所花的时间、通过结构的交换器转移包的时间，以及接收包并将它传递给一个软件实体的时间。这些元件中每个元件的延迟都可能受到流量控制的影响。 如果系统的结构中没有资源争用，那么就没有必要进行流量控制。流量控制机制做出决定，哪些包将要发送，以及如何为不同的包流量分配系统资源。在一个具有复杂和动态流量模式的系统中，流量控制机制能够以一种最大限度地提高系统性能的方式解决拥塞情况。如前所述，系统性能可能取决于消息传输延迟，以及结构中的整体吞吐量。为短期、中期和长期拥塞补充流量控制机制有助于系统设计人员优化其应用的性能特点。 一般来说，一个流量控制机制应使包尽早得到转发。在出现争用的条件下，缓冲区应该得到充分利用，以创建更多的调度方案，提高吞吐量和减少延迟。RapidIO和DCE流量控制策略的比较如下。 RapidIO实现了一个全面的流量控制策略，以解决一个系统中短期、中期和长期的拥塞情况。历时10微秒或以下的短期拥塞是由链路级流量控制来管理的。长达200微秒的中期拥塞以及负载平衡是由虚拟输出队列背压机制来管理的。长期拥塞是通过使用虚拟通道带宽保证，以及数据流包支持的基于速率和信用的流量控制来管理和/或避免的。 RapidIO链路级流量控制可通过短“控制符号”来实现，控制符号可以嵌入在包内。流量控制可以用8个优先权支持一个“优先”通道也可以支持多达8个“虚拟”通道而这些通道没有优先权，控制符号的控制路径延迟最小。在最坏的情况下(一个传输延迟时间为500纳秒、超过100米的以10 Gbps运行的光链路)在每个方向上的控制路径延迟约为最大大小RapidIO包的两倍半。 RapidIO流量控制机制允许一个发送器完全充分地对接收缓冲区进行打包。出于以下几个原因这样做非常重要： ? 一个交换芯片在其缓冲区中的包越多，无拥塞的路由包到输出端口的吞吐量增加选择就越多。这将以最小的延迟带来尽可能最大的吞吐量。 ? 发送器和接收器已就每个优先/虚拟通道可以转移多少包达成一致。当包传输调度时，发送器可以使用此信息优化结构延迟性能。 ? 低延迟控制机制允许尽量减少RapidIO缓冲区大小，同时保证包传送，并实现线速吞吐量。 基于IEEE 802.1p优先权的流量控制支持8个独立流，与RapidIO的8个优先权相同。建议使用暂停包，暂停包要采用一个定时的XON/XOFF机制。在接收器有可能用完缓冲空间之前，必须激活XON/XOFF机制，否则将会丢包。作用于流量控制的延迟的关键是有效利用缓冲区。在一个设备决定必须发出一个暂停包开始的时间到接收站因收到暂停包开始响应的时间之中，接收到的信息量被称为“滑移（skid）”。 从图2可以很清楚地看到，为什么能够在包内嵌入链路级流量控制信息对RapidIO来说是一个重要优势。在第1点，接收器决定它必须关闭一个特定优先权。然而，黄色的最大帧（第2点）已开始传输，以防止暂停帧的传输。这使得接收器可以接收相应的黄色最大帧。一旦发送器收到了暂停帧，在第3点就可能出现一个类似的问题，其中一个最大帧已经开始传输。因此，以太网连接必须考虑的最低滑移的大小是两个最大包。对于长度为100米的10 Gbps连接，计算出来的滑移长度约为10.1 KB。该计算假设的是一个长度为2000字节的最大包。如果使用了其他存储相关的协议，如采用2.5 KB最大传输单元（MTU）的FCoE或9 KB的MTU的iSCSI（互联网SCSI），滑移长度将会增加。其他以太网规范，如以太网，甚至可能会增加更大滑移长度。 如果以太网交换机支持8个独立优先权，就像Gen 2 RapidIO交换器那样，言下之意是，当有足够的缓冲区来弥补滑移时，必须优先考虑XOFFed。对于NIC和采用千兆字节DRAM的处理器来说，滑移长度并不值得担心。然而，对于交换器内的嵌入式内存，滑移长度具有重要意义。大滑移长度对以太网交换机的设计人员和数据中心以太网的用户有很大的影响： ? 为了避免发送暂停帧出现背靠背的情况，在开始运作一个流之前，应该有超出滑移长度缓存可以利用。这意味着，给定流量的包传输将会突发，从而造成不平衡的网络行为。 ? 无法保证发送的滑移包匹配正在关闭的优先权。因此，需要为滑移预留的一部分缓冲区将不包含数据包，从而增加了传输延迟并使吞吐量下降。 ? 为了减少一个以太网端口所需的内存数量，一种设计优化是将用于流量控制的多个优先权编组在一起。这可能导致线头拥塞，吞吐量出现相应下降，同时延迟增加。 ? 包传输调度算法可以补偿流量控制的不力。 虽然短期流量控制不具备传统以太网的优势，但长期流量控制具有这种优势。有许多协议旨在确定什么是可能实现的最高传输水平。这些基于软件的协议一般依靠在互联网以太网设备由于流量拥塞出现的丢包时进行丢包检测。随着DCE的问世，不再有丢包现象出现，使这些长期拥塞管理/传输速率控制协议失去了作用。相反，DCE要求支持802.1Q虚拟局域网标准。该标准对流量控制的影响稍后将在本文中讨论。 RapidIO Gen2规范为基于数据流包的流量创建了XON/XOFF，以及基于速率和信用的流量控制机制。这一机制是专门为单一目的地的多个发送器的系统开发的。该协议允许发送器之间进行通信，了解它们有多少信息可用，并针对目的地进行管理和调度，使哪一个发送器处于激活状态，并以什么速度运行。虽然流量控制机制可以用软件来支持，但是包格式很简单，用硬件也可以支持这些机制。正确使用这些流量控制机制就能够避免长期拥塞，并有助于优化应用的性能。 解决网络拥塞和流量控制问题的一个理想方案是得知网络中的拥塞位置，允许包源将传输的包调度到网络的非拥塞区域。RapidIO支持网络中的拥塞位置告知机制。RapidIO Gen2定义一个了低延迟的、基于控制符号的机制，名为虚拟输出队列（VoQ）背压。VoQ背压定义了一种分层的方法，可以用硬件来实现，将拥塞推回到网络边缘。这样做有两个好处： ? 它可以减缓造成拥塞点的流量，释放系统资源。 ? 它鼓励那些不会造成拥塞的其他流量的传输，从而提高吞吐量和平衡系统负载。 |
楼主
标题置顶
标题高亮
