外文翻译---网络子系统设计 中文版.doc

网络子系统设计单纯使用技术来避免工作站上CPU和存储器的瓶颈是不够的，必须要把技术集成起来。PeterDruschel,MarkB.Abbott,MachaelA.Pagels,LarryL.Peterson新兴的网络技术期望给终端工作站提供接近1Gbps的传输带宽，这样的带宽足以带动一类新的应用火热起来。然而，这些得益于高速网络的应用受到一些因素的制约，其中的一个重要因素就是运行在工作站上的操作系统。操作系统必须将良好的网络吞吐率转换为良好的应用程序间吞吐率。Arizona大学的网络系统研究小组（NetworkSystemsResearchGroup,以下简称NSRG）正在研究操作系统支持高速网络的相关问题。这些实验性的工作是在MachOS操作系统的x核心1环境下完成的。研制的系统运行在DecStation5000/200以及HP9000/720工作站上，这些工作站连接着ATM网络和FDDI网络。大体来讲，Mach系统提供了一个基于微内核的操作系统框架，而x内核相当于其中的网络子系统。我们先在逻辑上将所有的网络协议集中于单个x内核协议树中，然后在物理上将这个图结构分布在整个系统中，包括操作系统和应用程序保护域（applicationprotectiondomain）。例如，图1描述了一个协议树，它连接了一个应用程序、一台专用网络服务器，以及内核。一个特定的协议属于哪个保护域要等到配置时（不是操作系统设计时间）才能决定，从而也能够根据系统配置员对于性能和信任处理的意愿程度。要优化这种结构的性能，就必须解决工作站的存储器结构限制。问题在于工作站存储器性能的提升跟不上处理其性能和网络带宽提升的步伐。例如，Hennessy和Patterson报告指出，自从1985年以来，处理器的性能一直以每年50%-100%的速率提升，而存储器的性能提升速率只有7%。而且，我们希望这种趋势能够持续下去，因为处于开销的考虑，我们将会避免在这类机器上使用非常快的主存和互联技术。应当记住我们考虑的是数据在一个基于微内核的系统中的流动，在这种系统中，设备驱动程序、网络协议以及应用软件都可能驻留在不同的保护域中。我们相信把话题集中于此是很适合基于微内核的系统的优点的（可配置性、可分布性以及可移植性），也适合于当前商业领域中对这类系统的支持趋势。我们想说明的是，在不考虑操作系统结构的情况下，取得高的应用带宽也是可能的。本文讨论了工作站CPU/存储器的带宽和网络的带宽将保持在同一个数量级，从而，网络子系统必须要致力于使网络数据在CPU/存储器数据路径上的跳步数最小。本文也对一些应用于这些问题的技术进行了研究，得到的一个重要结论是单纯的应用这些技术对取得应用程序间吞吐率是不够的，也必须把从一个源设备，通过操作系统，到达应用程序，还可能到达终端设备的整个数据路径集成起来。本文在总结中列出了一个使端对端吞吐率得到最优化的完整数据路径。工作站硬件的性能在这一节中我们分析桌面工作站硬件影响输入输出数据流量的性能参数，包括了对目前商用工作站的测试以及下一代工作站相关参数的预测。表1中给出了四种商用工作站存储子系统的存储器峰值带宽（取自于硬件规格），以及部分CPU/存储器带宽测量数据。存储器峰值带宽是存储子系统在突发模式传输下能够达到的带宽。括号中给出的是测量到的带宽对峰值带宽的比例。图1:分布式协议图表1：一些工作站的存储器带宽表1中的CPU/存储器带宽数值是使用一个普通测试台程序测算得到的。该测试台程序测试的是一组读、写、复制操作过程中支持的带宽。测试台程序用C语言编写，在各工作站自身的C编译器下编译，并得到了最高级的优化，但是C源代码或者生成的机器代码没有针对特定机器进行改写。“读”、“写”两列测试的是对一个数组中单元素进行读（写），而“复制”列使用了两种方法测量：一种是数组元素形式的赋值，另一个是调用库函数bcopy（）。测试台程序使用了int类型（32位）和double类型（64位）数组，给出的数据都是各自条件下所能取得的最佳值。测试的主要结果是标准带宽仅为峰值带宽的一小部分，特别是读带宽为峰值带宽的15%38%，复制带宽仅为10%19%。带宽的下降是由两方面局限性综合影响的结果：第一，编译器生成的机器代码和厂家提供的bcopy()函数对于执行基准程序故意设定的工作是不够理想的。但是我们尽量不排除它，因为这个局限性对真实程序同样会有影响。第二，硬件强制性会限制带宽，即CPU能支持的带宽是有限的。尽管动态RAM存在很大的相关访问延迟，所有存储子系统都使用了某些形式的流水线（交叉式/页式）来获得高带宽。在传输时间中初始化延迟是比较大的，所以对于少量数据传输其平均带宽会降低。由于传输线路宽度限制，Cache和存储器之间的数据传输不能获得大部分的峰值带宽。由此我们得出，当前工作站的CPU/存储器带宽不超过其网络带宽的规定量级几百Mbps。下一代工作站将支持1Gbps网络适配器，它可以以网络速率将数据传送到主存。持续增长的CPU速度不久将允许以该速率处理软件数据。例如，DEC公司的Alpha处理器首次运行，允许以1Gbps带宽传输数据流，每个机器字包含1224条可执行的CPU指令。然而，人们没有把希望寄托在CPU/存储器带宽的急剧增加上。存储器峰值带宽可以通过增加存储器宽度来提高，但是，Cache的线宽必须成比例的增加才能实质性的增加CPU带宽。因此，就是要找到一个理想的合适的比率，很明显如果太小就不能获得大部分的峰值带宽。另一个方法是降低传输延迟，但是动态RAM（DRAM）的访问时间被认为已经接近其技术极限。几个最近公布的器件在DRAM上集成了Cache来降低平均访问延迟4。这些集成的二级Cache使用大线宽，用宽数据通路与DRAM相连。对于任何Cache，其合适的比率的设定依赖于它们所处的位置。我们下边将要谈到数据I/O访问表现很差。因此，我们希望下一代桌面工作站的CPU/存储器带宽和网络带宽处于同一量级。数据Cache的作用工作站使用Cache来缓冲CPU与主存之间的速度差。该思想是在CPU附近设置一个高速存储器，用来存储主存中部分数据。Cache通过降低数据和指令的平均访问延迟来提高系统性能，也降低了在共享存储器的多处理器系统中对存储器的争夺。然而，Cache的效果受到一些因素的影响：如Cache的大小和组织，数据访问的位置和处理器调度。假设系统支持处理全部应用级高带宽数据，处理数据时需要CPU对数据单元的每个字进行检查和可能的修改，潜在的多次访问。（下一节将确定几个数据可能通过CPU/存储器数据通道的原因。）本节讨论数据Cache在避免CPU/存储器间传输上效果不明显。考虑以下重要因素：处理器调度CPU调度可能导致在执行其它程序时插入对数据单元的处理进程，当返回重新执行时，很可能缓冲的数据已经被替换。在一个多处理器系统上，进程可能被拥有自己数据缓冲的不同的CPU重新调度。在处理数据单元时有几种情况会发生调度：当数据单元要被传递给另外的线程（如队列），处理器必须调度执行该线程；在某种协议下，队列典型性的产生在用户和系统接口处，在设备驱动的中断句柄和驱动的顶层之间；在最差的情况下，在协议层之间会产生附加队列；还有硬件中断及信号触发处理器重新调度的事件。写策略多处理器数据Cache通常采用写穿透策略，即每个写操作都要写回主存。写缓冲与写穿透Cache一起被使用来减少CPU回写存储器的时间。但是，许多连续写如要对一个数据单元读写每一个字时将发生仍然会造成CPU执行存储指令时等待。Cache查找Cache实际上是索引和标记，访问Cache中的数据不需要虚存地址到物理地址的译码。以这种方法，从虚拟共享页来的缓冲数据若超过保护域边界就不能保持其有效，物理上标记的缓冲不存在这样的问题。但是，需要一个包含参考数据的辅助翻译缓冲（TLB）处于活跃状态。Cache容量数据Cache速度很快，容量有限。因为留在Cache中的数据检查和修改的过程包括读取和存储每个字，所以Cache必须至少是数据单元的两倍大。在实际情况下，由于Cache有限的连接产生线路冲突和在数据处理过程中要访问程序变量使得对Cache容量的要求进一步增加了。为了量化数据Cache处理网络数据的效果，我们进行了一些初步的实验，测量了在操作系统运转以后驻留内存的网络数据量。这个值反映了由于缓冲网络数据，避免了CPU/存储器数据传输给用户进程带来的潜在的好处。它给出了Cache在没有网络数据复制情况下能提供的最大好处。这些实验是在装有Mach3.0（MK67）的HP9000/720工作站上运行的。这些工作站配有256KB虚拟索引物理标记的数据Cache。Mach3.0运行着称为via的UNIX操作系统和称为UnixServer的用户进程。UnixServer接收用户进程的请求UNIX系统调用信息，并由Mach的微内核来使能设备请求的的处理。到达的网络报文被微内核通过中断服务机制接收，复制并压缩为一个Mach信息，然后发送给UnixServer通过其协议栈来处理。如果一个网络报文包含的数据被另一个用户进程预定，它必须从UnixServer的地址空间复制到目标地址空间。由于Mach的Unixserver包含了典型UNIX单片机上的全部网络代码，所以它接收网络数据信息并将其复制到最终用户这个过程接近于模拟了UNIX单片机处理网络报文的过程。实验测量了在UnixServer将网络数据复制到其用户地址空间之前，驻留Cache的网络数据量。如果UnixServer执行一个随意复制的网络数据系统，UnixServer在复制点所能看到的在Cache中的驻留部分也将被接收用户进程看到。公布的结果是在关闭UDP校验时获得的，若打开校验，Cache中的驻留部分将会增加，因为上下文切换的机会将降低并且校验码会导致对大量缓冲报文数据的读取。对于MachUnixServer在收集数据方面的修改细节见参考文献5。收集实验数据会出现两种情况：第一，接收处理器仅运行普通的系统程序和实验接收程序的轻负载状态；第二，接收处理器正在接收从第三方处理器快速传送的8000字节UDP报文的重负载状态。图2画出了200次测试时钟周期数的算术平均值，对比了要访问的网络缓冲数据是否全在Cache中和UDP数据包大小的关系。“100%未命中”曲线显示在网络数据缓冲中使用全部的Cache线，将数据从主存读到Cache中需要的时钟数。注意我们测试的两种情况下的数字均超过了100%Cache未命中时的结果。