我以前所做的几个嵌入式设计项目都需要这样或那样的网络连接，这些项目不断重复着同一主题，即嵌入式系统需要通过标准网络接口与外界进行通讯。这些项目通常包括实时操作系统(RTOS)和常规网络模式：以太网、TCP/IP和套接API。通常，这些系统中的以太网数据处理要么以非实时数据的形式转交给后台处理，要么数据本质上是可循环的，只要数据在一段时间内进行刷新(约15至30毫秒)，一切都可正常工作。换言之，我们并不奢望小于几个毫秒的精度。
然而，我近承担了一项特殊的系统设计项目，该系统需要一个极低延迟时间的确定性网络作为这一项目的核心。这促使我研究确定一般的网络工具是否适合该任务。尽管研究期间可以参阅许多的网络理论、标准化协议和结构性原理，但性能规范始终难以捉摸，因为网络系统存在许多不可预知的因素，如网络硬件、网络软件、计算机硬件及操作系统等。通过这项研究，我加深了对TCP/IP和以太网性能特征的实际了解，而这些细节只能通过给定网络的实际运用在实践中获得。
该项目的目标是通过嵌入式I/O处理器网络来替代飞行模拟器中包含1,000多个I/O的高度集中式I/O系统，从而降低生产和设计成本。另外，由于降低了配线复杂性，生产效率预计也有所提高。新的分布式I/O系统包含许多远程节点(位于其所服务的面板和仪器附近)，这些远程节点相互连接，可在仿真处理器和各种飞行器及模拟器设备之间传送数据。
初，以太网被认为是的网络媒介选择，它的确能够满足低廉硬件、低生产成本以及每个模拟器包含50至70个 I/O节点的要求。毕竟，集成有以太网功能的CPU面板随处都可买到，因此可大大降低成本。图1描述了初设想的模拟计算机系统布局，它在分布式I/O中利用以太网作为网络媒介。
然而，由于以太网是非确定性的，因此需要评估其它媒介。我们评估了各种网络总线，包括反射式存储器、现场总线(通常用于工厂自动化)、RS-485等，结果表明它们都不能经济有效地满足要求。以太网看来是合适的，缺陷是非确定性数据传输(尽管已广受注目)。此外，还必须研究以太网是否适用于要求较少延迟时间和确定性行为的系统。
以太网、TCP、UDP和IP
我曾多次听到同仁们这样老生常谈：“以太网是非确定性的”。但是，以太网究竟不确定在哪儿？是因为它不受限制，还是仅仅定义适用公差的问题？为解决这些问题，让我们先从以太网和TCP/IP的基本概念入手，做一下深入探讨。
大多数应用程序通过TCP/IP协议栈与以太网相联，该协议栈采用分层的方式实现组成TCP/IP的各种子协议。在网络界，TCP/IP是一套基于因特网协议(IP)的协议集的统称，TCP是众多协议中的一个。TCP/IP协议栈位于以太网驱动器之上，并与之紧密配合。换言之，TCP/IP通过排列输出数据、缓冲输入数据及提供网间路由机制，来协调应用软件和网络驱动器之间的数据(信息包)流动。简单的说，测试应用软件是通过套接API来访问TCP/IP协议栈的。
TCP/IP协议提供了两种可选的数据传输协议：TCP或UDP。两者的差别在于TCP可提供可靠的连接，确保接收方能收到所发送的每个信息包。而UDP是一种送毕即弃的协议，如果需要接收方确认，应用软件本身必须提供确认方式。人们或许倾向于更可靠的协议，但必须认识到可靠性是要付出代价的。
通过TCP协议发送的每一个信息包都要触发接收堆栈发回一个确认信息包。对于少量数据而言，性能代价相当不合算。例如，如果要传输1字节的数据，须通过网络传输一个64字节的信息包(以太网信息包的小尺寸)，并相应地发回一个64字节的确认信息包，这使得整个网络的通信量增大一倍。在同样的情况下，使用UDP协议只需发送初始信息包即可。因此，使用TCP协议将会给网络添加不必要的开销，而网络并不需要更多的可靠性。
我们利用以太网硬件设备，即网络接口(NI)，来连接网络媒介。NI采用一种两阶段总线仲裁方案，即载波侦听多路访问与冲突检测(CSMA/CD)，因此当设备检测到总线未被占用时，便发送数据，这是总线仲裁协议的CSMA部分。该方案允许两个或更多设备同时在总线上传输数据，这正是CD(冲突检测)部分的由来。如果同时访问总线的情景发生，设备便检测到“冲突”，经过一段随机延迟时间，再重新向总线发送数据，直到发送成功为止。这就是以太网基本的不确定性特征，然而，如果总线仲裁方案能在更高一级实现的话，还是有可能超越CSMA/CD方案的。
为克服以太网不可预测的仲裁方案，我们采用了一种软件协议，规定网络设备只有得到许可才能访问总线。该协议并不限制CSMA/CD的使用，而只对控制以太网媒介访问的(应用)软件起约束作用。为使该方案行之有效，必须建立以下规则：仅专有节点才能连接到网络上；一个设备被指定为控制器，其余设备视为远程节点；除非控制器发出请求，否则远程节点不能访问网络总线；远程节点有预先设定的时间来响应控制器请求。
我们为控制器节点设计了一个测试程序，控制器节点中的数据通过网络传送到远程节点。该程序等待远程节点的响应数据，然后将其与原始传送数据做比较，以检测是否出错。如果两个数据不一致，或者过了预定时间远程节点仍未做出响应，测试程序便生成一个出错信息。控制器软件还可记录信息包往返的长、短及平均时间。远程节点软件只等待控制器发来的输入网络数据，一旦收到数据，将对控制器做出回应。观测这些协作程序产生的往返数据处理时间可用于评价系统的性能。
投入测试
我们搭建的原型网络由2个节点(控制器节点和远程节点)组成，通过10BaseT以太网连接，以方便收集实验网络的吞吐量和测定时间。我们选用Phar Lap的TNT实时内核作为所有节点的运行环境。除该内核外，还用到了Phar Lap以太网设备驱动器和TCP/IP协议栈。我们为每一节点选用了Ampro 486级100MHz PC/104板。尽管我们的目标是在产品中使用带有集成以太网10BaseT端口的CPU，但目前尚不可得。因此为了进行测试，我们使用了带有SMC 91C94以太网接口芯片的Ampro PC/104网络接口卡。将一个示波器连接到每一节点的并行端口也有利于时序分析；应用软件中某些数据位随重要事件而设定和清除，它们被用作时序指示器。使用示波器对于该项目来说或许有点大材小用，但它提供了“清楚的校验”，而且看来棒极了，尤其是对广大的软件工程人员而言。图2示出了这一测试系统。
在控制器和远程节点程序的逻辑序列中，控制器节点调用速率为60Hz，而远程节点则不断地循环。在控制器初始化阶段，也会将信息包发往远程节点。这迫使ARP协议接受初始化的影响，从而不干扰我们的实时测量。
对结果波形和软件累加器的分析表明，2ms是的往返时间，在此期间可向远程节点发送64字节的有效载荷，并保证控制器收到响应信息包；坏情况下的往返时间为6ms。
单个节点完成往返处理必需的循环时间为16.7ms (相应的频率为60Hz)，坏情况下的往返时间为6ms，该系统只能可靠地支持两个远程节点。显然，该方案只能提供较小的吞吐量，对于单个飞行模拟器而言，需要25个或更多的这种独立网络。因此该系统需要巨大的性能突破，才能作为传统堆架式I/O的一种可行替代方案。
保留TCP/IP
有两个问题是显而易见的。首先，对于10Mbps的信号速率，即便情况下的2ms仍是很长的延迟时间；其次，所产生的抖动十分严重。我们将在稍后讨论抖动问题。至于延迟时间，探讨一下穿过导线的信息将对其时序特征的了解有所启发。
测试中，我们向TCP/IP协议栈发送了64字节数据。如图3所示，随着协议报头开销的增加，信息包到达总线时，这64字节数据将变为庞大的128字节。让我们来计算一下126字节在10Mbps以太网上往返一次所需的短时间。126字节等于1,008位，乘以100ns(10MHz的倒数)得到100.8μs，再乘以2(因为数据被发送回来)，终得到的往返时间为201.6μs。我们忽略了像传播时滞这样的次要因素，而实际上是达不到这一理论极限值的。但通过测量可知，情况下的结果是该极限值的10倍。可见这并不太有效！
早期带有可变负载的内核测试显示，只要涉及定时和时序，内核性能是一致不变的。因此，我们认为延迟时间和抖动很大程度上可能是由TCP/IP协议栈或设备驱动器引起的。于是，我决定重写软件程序，但不使用TCP/IP协议。由于Phar Lap网络驱动器接口表现良好，而且使用现有的驱动器仍可保持部分硬件独立性，因此，该计划是要修改应用程序代码的网络访问模块，以便直接与设备驱动器连接，而非套接库。
这项修改绝非无足轻重，我们必须创建缓冲管理和信息包结构代码。这些改变使得应用程序代码的移植性下降，因为它变得仅适用于某一特定的操作系统。然而，如果性能的提高能带来成本效益，那么这种折衷还是值得的。
软件修改完成后，相同的程序(见表1和表2)将再次运行。情况下的往返时间为0.45ms，而坏情况下为0.6ms。这一修改是分布式I/O项目开发中的重要步骤，它将坏情况下的性能提高了一个数量级。性能的提高应部分归功于信息包开销的降低，这固然缘于摒弃了UDP和IP报头，但更大程度上还在于数据无需通过功能更多的协议栈。
在新的结构中，每个网络系统能在要求速率下，以小有效载荷支持20个远程I/O节点。
图4是从连接到原型系统并行端口的示波器捕获的屏幕图像，以下是对其迹线的描述：
曲线：当准备好的信息包发送到设备驱动器时，控制器节点信号设定为高电平；当控制从驱动器返回时设定为低电平。信号的上升沿位于信息包往返定时开始之际。
次高曲线：当收到的信息包正确时，第二控制器节点信号设定为高电平；当信息包收到时，信号设定为低电平。信号下降沿表明信息包一次往返的结束。
次低曲线：当驱动器通报信息包可用时，第三远程节点信号设定为高电平；当应用程序重新收到该信息包时，信号设定为低电平。
曲线：在信息包传输之前，第四远程节点信号设定为高电平；当控制在通知驱动器发送信息包返回时，信号设定为低电平。这段时间包含从接受信息包到传输信息包期间复制数据的时间。
图5在原型系统经验值的基础上，显示了平均信息包大小对往返时间的影响。值得注意的是，由于以太网规定了信息包的小长度，往返时间绝不会低于500μs。
构建系统
控制器节点将解析配置文件，并为每一远程节点存储配置信息。当远程节点在线时，这些信息可通过网络动态配置远程节点。为确保系统的确定性，网络中的远程节点只有先收到控制器的传输请求，才能在以太网总线上传输。此时它将向控制器发送一个信息包，该信息包与来自控制器的信息包类型应相互匹配。换言之，如果控制器发送了一个数据包，指定的远程节点必须发回一个数据包。同样地，如果控制器发送了一个配置信息包，则适合的响应也是配置响应信息包。远程节点必须在两次接收控制器信息包期间完成所有的数据处理和I/O扫描。
为限度地利用CPU，控制器总是在等待当前节点响应数据包到达期间处理前一个节点收到的信息包，然后再处理下一个节点传输的信息包。例如，如果控制器刚给远程节点3发送了一个信息包，控制器接着将处理先前从节点2接收到的数据(如果有的话)；然后着手构建发往节点4(或任意下一节点)的信息包；控制器等待来自节点3的信息包或暂停工作；随后，再将先前构造的信息包发送给节点4，接着处理来自节点3的数据，如此不断循环下去。
分布式I/O网络中的信息包符合图3顶部所示的以太网帧格式，帧类型字段用于确定发往接收节点的帧功能，表1列出了所用类型的描述。类型字段之后的8位字段是节点ID，不管信息包发往何处，它总是携带远程节点的ID。节点ID之后是一个8位错误代码字段，信息包的剩余部分是用户数据。
每个节点在专有I/O板上都有一个8位端口，系统由此确认该节点。对每一个登录在配置文件中的远程节点，控制器都会利用(自带的)MAC地址查询(MAQ)协议来广播节点的以太网MAC地址请求。在配置合适的系统中，只有一个远程节点能响应给定的MAQ。与MAQ信息包节点ID匹配的远程节点通过发送MAQ响应信息包对控制器做出响应。远程节点还保存了MAQ信息包的源地址，该地址在随后所有的传输中可用来填充目的地址字段。MAQ响应信息包的源字段中包含了响应节点的MAC地址。接着，控制器将此地址存入列表以便将来建立该响应节点的索引(这很像ARP)。
确定节点MAC地址后就向其发送配置信息包。远程节点以配置响应信息包的形式响应每个配置信息包，以通知控制器信息包已收到。远程节点将收到的配置信息包存储起来，并用于实时数据转换和定标。
每个分布式I/O网络的控制器都以一定的配置速率(即帧速率)进行循环。帧速率的范围为1Hz 到100Hz，帧速率的1/2、1/4、1/8和1/16等次速率可按节点来分配。这些次速率可用于更密集的系统(网络中有更多节点)，而且不会与高速节点的定时要求发生冲突。
此外，采用网络分析仪可追踪远程MAC地址获取、配置循环和正常数据传输这一系列事件的序列。但须注意，时间字段的精确度为1ms，在1ms内可发生多次传输，时间字段还表明控制器的帧速率为60Hz。
结论
我并非有意摒弃TCP/IP。相反，该项目使我对这一重要协议有了更深入的了解，希望将来有机会将这些认识应用于实践。我确信，当带有集成100Mb(或1Gb)以太网端口的小型CPU变得经济可行时，我们将有机会在分布式I/O中再次采用TCP/IP协议。