系统需要通过标准网络接口与外界进行通讯，常规网络包括以太网、TCP/IP和套接API。人们通常认为以太网具有非确定性，但是，本文通过测试和研究表明，当集成了100Mb(或1Gb)以太网端口的小型CPU成本经济、性能可行时，将有机会在分布式I/O中采用TCP/IP。
我以前所做的几个设计项目都需要这样或那样的网络连接，这些项目不断重复着同一主题，即嵌入式系统需要通过标准网络接口与外界进行通讯。这些项目通常包括实时操作系统(RTOS)和常规网络模式：以太网、TCP/IP和套接API。通常，这些系统中的以太网数据处理要么以非实时数据的形式转交给后台处理，要么数据本质上是可循环的，只要数据在一段时间内进行刷新(约15至30毫秒)，一切都可正常工作。换言之，我们并不奢望小于几个毫秒的精度。
然而，我最近承担了一项特殊的系统设计项目，该系统需要一个极低延迟时间的确定性网络作为这一项目的核心。这促使我研究确定一般的网络工具是否适合该任务。尽管研究期间可以参阅许多优秀的网络理论、标准化和结构性原理，但性能规范始终难以捉摸，因为网络系统存在许多不可预知的因素，如网络硬件、网络软件、计算机硬件及操作系统等。通过这项研究，我加深了对TCP/IP和以太网性能特征的实际了解，而这些细节只能通过给定网络的实际运用在实践中获得。
该项目的目标是通过嵌入式I/O处理器网络来替代飞行模拟器中包含1,000多个I/O的高度集中式I/O系统，从而降低生产和设计成本。另外，由于降低了配线复杂性，生产效率预计也有所提高。新的分布式I/O系统包含许多远程节点(位于其所服务的面板和仪器附近)，这些远程节点相互连接，可在仿真处理器和各种飞行器及模拟器设备之间传送数据。
最初，以太网被认为是最佳的网络媒介选择，它的确能够满足低廉硬件、低生产成本以及每个模拟器包含50至70个
I/O节点的要求。毕竟，集成有以太网功能的CPU面板随处都可买到，因此可大大降低成本。
然而，由于以太网是非确定性的，因此需要评估其它媒介。我们评估了各种网络总线，包括反射式器、现场总线(通常用于工厂自动化)、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网络接口卡。将一个示波器连接到每一节点的并行端口也有利于时序分析；应用软件中某些数据位随重要事件而设定和清除，它们被用作时序指示器。使用示波器对于该项目来说或许有点大材小用，但它提供了“清楚的校验”，而且看来棒极了，尤其是对广大的软件工程人员而言。
在控制器和远程节点程序的逻辑序列中，控制器节点调用速率为60Hz，而远程节点则不断地循环。在控制器初始化阶段，也会将信息包发往远程节点。这迫使ARP协议接受初始化的影响，从而不干扰我们的实时测量。
对结果波形和软件累加器的分析表明，2ms是最佳的往返时间，在此期间可向远程节点发送64字节的有效载荷，并保证控制器收到响应信息包；最坏情况下的往返时间为6ms。
单个节点完成往返处理必需的循环时间为16.7ms(相应的频率为60Hz)，最坏情况下的往返时间为6ms，该系统只能可靠地支持两个远程节点。显然，该方案只能提供较小的吞吐量，对于单个飞行模拟器而言，需要25个或更多的这种独立网络。因此该系统需要巨大的性能突破，才能作为传统堆架式I/O的一种可行替代方案。
保留TCP/IP有两个问题是显而易见的。首先，对于10Mbps的信号速率，即便最佳情况下的2ms仍是很长的延迟时间；其次，所产生的抖动十分严重。我们将在稍后讨论抖动问题。至于延迟时间，探讨一下穿过导线的信息将对其时序特征的了解有所启发。
测试中，我们向TCP/IP协议栈发送了64字节数据。随着协议报头开销的增加，信息包到达总线时，这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节点。
最高曲线：当准备好的信息包发送到设备驱动器时，第一控制器节点信号设定为高电平；当控制从驱动器返回时设定为低电平。信号的上升沿位于信息包往返定时开始之际。
次高曲线：当收到的信息
【责编:admin】
--------------------next---------------------
