1、一种使用实时文件系统可扩展硬盘录像解决方案摘要我们提出了一个可扩展的解决方案：除了支持非实时的类 PC 应用外，还允许单主流硬盘驱动器同时录制和回放多个实时视频流。我们的解决方案能够同时处理不同类型的硬盘、不同数量的不同比特率流以及任意非实时应用。关键词硬盘驱动器 视频录制 实时 文件系统.引言主流 IDE 硬盘驱动器（ HDD）已启用随机访问的大容量存储用于家庭音频/视频（A/V）应用程序。不断提高的硬盘驱动器性能与容量使得其能够在 CE 设备上启用革命性功能，如个人视频录制、时移节目、网络冲浪、游戏、使用广播、网络服务以及其他有趣的个人电脑（PC）功能对私人和公开视音频内容信息实现智能化收
2、藏和导航。对于一台能够支持上述令人振奋的功能的高级家庭媒体服务器（HMS），除了支持非实时应用请求外，其硬盘驱动器还需要支持多个同步实时（RT ）视音频流。这种硬盘录制解决方案应该是可扩展的，而不应该对应用软件强加限制。尽管主流的硬盘驱动器已经达到较高吞吐量，如连续读取和写入达到 20MB/s，散乱的数据块的实际吞吐量可能是由于硬盘驱动器的切换开销低得无法接受。对于一台支持多用户多视音频流的高级家庭媒体服务器来说，系统需要硬盘驱动器吞吐量调度和在磁盘上视音频文件的适当分割去保证这些流的实时流吞吐量。基于 PC 文件系统的典型嵌入式系统的实现并不能提供流媒体保证，而且经常出现大量类 PC（非实时
3、）的磁盘请求需要被严格限制。一些实现是使用 PC 的文件系统上预先分配的文件，以避免视音频文件碎片化。但是，这需要为视音频内容准备单独的管理代码 。 PC 的文件系统的另一个问题，例如， FAT文件系统可能由于电源故障而损坏。典型的嵌入式实现方法没有特别的硬盘驱动器时间分配功能。磁盘吞吐量分配是在应用层进行，或者是依赖于应用程序。因此，它仅适用于专用的应用程序。一些实现方式一点也不关心流的性能;他们简单地认为足够高的磁盘吞吐量和在系统上运行的足够简单的应用程序便可。如果开发者想切换到不同类型的磁盘，或支持不同数量的具有不同比特率的流，或者对不同的连接功能进行升级以及开发其他 PC 功能，上述的
4、实现方式往往需要显著的再设计的努力。我们提出的解决方案具有所需的可扩展性，并且能强有力地对抗电源故障。.流的实时性能保证在享受视音频内容时，消费者不接受视觉或听觉上的现象，如丢失帧、（MPEG-2）块效应、图像短暂性问题、发出怪声等等。这些现象可能由流媒体处理链的任何组件引起，例如一个硬盘驱动器，编码器/解码器、缓冲区、总线、 CPU 等。着眼于本文所使用的硬盘驱动器，我们想要通过为每个流保证足够的吞吐量来保证实时流媒体性能。换句话说，硬盘驱动器和流处理链之间的数据流缓冲器从不溢出（用于记录到 HDD）或下溢（用于播放）。由于延迟和成本我们还希望缓冲大小要尽量小。我们要保证数据流性能独立于随机
5、非实时磁盘请求。上述要求只能达到可预测的硬盘驱动器性能。然而，对于目前的标准（ATA-6 和之前的版本）IDE 磁盘，造成驱动器的错误恢复过程（ERP）的时间损失是不可预测的。本文中数据流吞吐量的保证是象征性的保证，这不把少见的的 ERP 情况考虑在内。我们假设 CPU 的等待时间足够低去及时发出 HDD 指令。这通常是正确的，因为 1毫秒延迟对 HDD 控制是可以接受的。我们还假设总线吞吐量和流处理链的其余部分具有足够的性能。A.流比特率上界虽然一个被压缩的视音频流，例如 MPEG2 数据流，可以具有可变比特速率，但其最大比特率通常是一个很好的上限来为流计算磁盘吞吐量保证值。最大比特率的条件
6、实际上会导致 HDD 吞吐量的过度保留。对于典型的 DVB 广播编码器，其平均比特率可以是 最大比特率的一半。如果其他磁盘请求不能利用保留用于可变比特率流的未消耗的时间的优势，该系统可能会浪费磁盘带宽。这种松散的时间可以用来提高用于非实时磁盘请求的吞吐量。B.可预测的硬盘性能主流的硬盘驱动器在磁道和扇区中部署媒体盘。一条磁道由一个圆形扇区组成，一个扇区由 512 个连续字节组成。忽略少见的 ERP 情况，一个磁盘请求的象征性指令完成时间是可预测的，并由寻道时间、旋转延迟和传输时间组成。寻道时间为磁头移动到目标磁道的时间，它可以与寻道距离的线性函数来建模。旋转延迟的时间花费在等待磁道上数据块的第
7、一个扇区上，平均为半个旋转周期，最大旋转延迟为一个旋转。传输时间为读取和写入连续扇区的时间，它改变盘片表面，因为分区而使磁道的扇区数不同。不同的硬盘驱动器如具有不同媒体密度、不同操作模式和不同表现形式，其性能也有所不同。参考文献1提出的方法来表征硬盘驱动器性能并预测给定磁盘请求的标称命令完成时间。访问分散的扇区花费明显的切换花销，其中包括寻道时间和旋转延迟。对于一个主流硬盘驱动器，一个完整的旋转时间多于传输 100KB 的所需时间。最大寻道时间（从最内到最外磁道）往往是一个旋转时间的 3-4 倍，这个时间等同于传输 500KB 的时间。一个草率的设计会很轻易地浪费一个硬盘驱动器的 90%的时间
8、在切换开销上，如磁头在访问几个扇区后移动。C.磁盘上数据碎片化在没有适当的数据碎片化限制的情况下，一个硬盘录像系统不能够保证视音频流的磁盘吞吐量。PC 世界标准的 FAT 文件系统无法为视频应用合适的碎片化限制，因为他们使用的小文件分配单元，如 4 - 64 KB。除非使用诸如预分配或预聚集文件的特殊技术，一个视频文件可以在磁盘上分散成小块，尤其是当该系统已于一个几乎完整的磁盘通常为 PVR 或HMS 应用程序中运行。使用大文件分配单元例如数百或数千个扇区，可以为视音频文件提供适当的碎片化限制。但这样的大分配单元浪费宝贵的磁盘容量在小（例如几千字节）的文件中，因为一个单元可以仅用于一个文件。使
9、用不同的分配单元大小能够节省容量，但它增加了文件系统的复杂性。一个实用的解决方案是使用多个具有不同的文件系统中的磁盘分区，但终端用户可能不喜欢固定的分区大小。D.HDD 吞吐量调度足够的磁盘吞吐量可以通过使用磁盘调度程序为每个实时流做保证。调度程序根据其比特率反复分配磁盘时间给每个数据流，因此数据流在播放期间不会消耗完数据或在录制过程中空间不足。基于周期的调度方法，例如单次扫描调度和双重扫描调度2，由重新排序的服务流的序列来优化磁盘切换开销。在一个周期内这些方法服务每个流一次。服务流的序列是有序的，这样该磁头在每个周期中一个或两个扫描单调移动。因此，无论流文件被分配到磁盘上什么位置，切换开销都
10、被最小化。因为这种调度的设计有“最坏情况”的边界条件，诸如最大比特率，最大切换开销和持续传输速度，在平均磁盘花费比估计用于服务的所有数据流的时间更少。节省下来的时间可用于非实时请求，如果设计者希望得到一定非实时吞吐量，他还可以为非实时请求保留一部分时间。E.HDD 错误修复大多数磁盘命令需要花费可预测的时间量。然而，在非常有限的磁盘命令的数目由于磁盘访问的错误而花费更多的时间，如数据误差和寻道错误等。当前的 IDE 硬盘使用不间断错误恢复过程（ERP）来进行错误恢复重试，这可能需要长达几秒钟。ERP 时间是不可预测的，并且不能被直接考虑到流性能保证中。如果 HDD 命中错误时，所有的数据流可能
11、会中断。为了使 ERP 的时间预测，流数据传输功能集的建议已被定义在 ATA 标准化委员会中3。此功能集允许授予时间预算给每个磁盘流命令。如果 HDD 不能及时完成命令，它将存储状态并带错及时返回到主机。这是主机（例如，调度算法）的责任去确定它是否有时间发出一个命令，以解决该错误。以这样的方式，一个磁盘访问错误仅影响发出该命令的流，其它流将不受影响。因为数据的完整性对于非实时请求很重要，调度程序应解决非实时请求的错误。功能集允许调度程序交错恢复具有流命令来保证实时吞吐量。它的一个额外机制，从报告的错误中诊断实际磁盘缺陷同样很有用。流式数据传输功能集可能在未来的 ATA 标准被认可。.解决方案为
12、了实现进阶的 HDD 录像机和家庭媒体服务器的一个可扩展的 HDD 录制解决方案，我们已经开发了实时文件系统（RTFS），以保证除了任意非实时磁盘请求的流媒体性能。图 1.使用 RTFS 的可扩展 HDD 录制解决方案A.体系结构图 1 展示出我们的解决方案的结构，应用程序可以在流模式或非实时模式下访问HDD 的文件，这与在 PC 上访问 HDD 是一样的。RTFS 在这个解决方案中起到关键作用。实时流使用 HDD 和流式设备如编码器、解码器、数字调谐器、家庭网络信道或其它数字输入/ 输出装置之间的 RTFS 取得。数据流缓冲器用由 RTFS 确定的优化尺寸使用于每个流。由 NTFS 或遗留的
13、 FS（嵌入在操作系统中）发出的非实时磁盘请求通过 RTFS 调度程序来完成。支持遗留文件系统能够使用/重用现有的非实时应用程序。在这种架构中，RTFS 文件系统层和传统的 FS（在各自的分区上）管理磁盘上的文件分配。只有在 RTFS 分区上的文件可以在保证吞吐量下进行流式处理，因为 RTFS 文件系统层可以提供适当的文件碎片化限制保证吞吐量。RTFS 调度程序是位于 HDD 驱动器顶部的一个组件，能够保证已寄存流的吞吐量。使用磁盘性能模型1来估计标称命令完成时，它的时间表从 RTFS 文件系统层和遗留的FS 接收挂起的请求，并使用 HDD 驱动预定顺序执行它们，使得每个流的吞吐量被保证。在我
14、们的解决方案中，流的工作方式如下：一个应用程序可以动态地启动一个新的采用 RTFS 中准入控制谈判机制产生的所需比特率的流。在协商中，RTFS 调度返回流缓冲器大小给应用程序。当录制流已经启动，流式设备会在数据流缓冲器中连续产生数据。这种数据生成的事件被信号发送 RTFS 周围的数据流线程，监视在流缓冲器的可用数据。文件系统层的一个流线程向调度程序发出流请求。使用基于周期的调度方法，调度程序使所有未处理的请求（来自所有流和非实时程序）的执行序列位于周期的开始。这种序列保证流的吞吐量和搜寻开销的最小化。如果总标称命令完成时间小于循环周期，非实时请求将被插入到序列中，接着调度程序逐一将请求序列发送
15、给 HDD。当 HDD 完成一个请求时，调度程序会返回一个确认信息到文件系统层或遗留的 FS。如果它是一个实时请求，流线程将接收到确认，然后释放在流缓冲器的空间。如果调度程序已收到新请求，序列完成后立即开始一个新的循环。这个流将如此继续直到应用程序停止流。流的结束将中止流设备、删除流的注册信息和在调度程序中分配的带宽、释放缓存并且杀死流线程本身。这同样适用于从磁盘到流设备的播放流。RTFS 是独立于应用的，这使得我们可以将 RTFS 用于各种程序中。磁盘调度器和组合的硬盘驱动器的行为相当于流磁盘。文件系统的附加功能使得 RTFS 成为流式文件系统。B.实时文件系统在文件系统层和磁盘调度程序中的
16、一些细节解释流吞吐量是如何保证的。1)文件系统层FS 层使用一个相当大的磁盘分配单元优化视频以尽量减少磁头跳跃和碎片化对流的负面影响。小的文件被预期放在磁盘上的其他分区，由于遗留的 FS 作为嵌入在操作系统中的用于引导，应用加载等。为了最大限度地减少切换开销，它仍然是优选避免请求分割在一个文件分配单元的边界。RTFS 使用分配单元的片段作为 HDD 的流访问入口的数据块大小。数据块的大小可以从所需流比特率和分配单元的大小获取。对 CE 设备来说，以防止文件系统由于电源故障而中断是非常重要的。 FS 层使用了一些磁盘上的文件系统管理信息表。这些表格以交替的方式自动更新，确保磁盘上总有一个有效的集
17、合以及维持系统完整性。然而，因为文件的文件系统管理信息尚未保存到磁盘，电源故障可能仍然导致的一些刚刚被写入该文件中的最新的内容损失。为了在接通电源后，以尽量减少潜在的数据丢失故障，系统设计人员还可以选择经常更新磁盘上的文件信息。FS 层具有正常的文件管理工具，如列出的文件和目录，打开和关闭文件等。一种桥可用于映射这些工具到操作系统的标准的文件系统的接口，以使任何第三方应用程序可以通过传统的 FS 接口访问以正常的非实时模式访问 RTFS 分区。2)磁盘调度程序在 RTFS 磁盘调度器使用基于周期的方法2 ，在重复的循环周期调度磁盘请求。在每个周期，它提供每个流足够大请求大小的一个请求使其能够生
18、存于整个周期中。如果所有注册流的总指令完成时间小于周期期间，数据流是调度，如在式（1）所示。(1)iidnrPBnSW)(/1式中，P 为周期，r i为所需比特率， Bi为周期中流 i 传输的数据块大小，r d为磁盘持续传输速率，SW(n)为具有 n 个流的一个周期中总切换开销的上界。磁盘的持续传输速率是最内部的磁道持续传输数据块的速率，这可能是最外磁道传输速率的一半。这是因为最外磁道具有多个扇区。总的切换开销包括用于周期中所有流的请求的寻道时间旋转延迟。如果不寻求优化，例如在一个固定的顺序供应流每个周期轮循调度时，SW(n)应计算一个完整寻求和用于每个流的完整的旋转。当流的数量增加，这个结果
19、在循环中会变得明显。对于一个周期以单调序列寻找的命令所有请求的单扫描调度来说，切换开销上限可以使用线性（沿寻道距离）寻找时间模型导出4。(2)RnsnsnW)()1()S1020在(2)式中，s 是全距离寻道时间，s 0是线性的寻道时间模型的偏移量（零寻道距离），n 是流的数目。(2)式的最后部分计算上界每个流一个完整的磁盘旋转 R，第一部分为半个全距离寻道，其界定序列中到达最近的最内/最外请求的寻道时间。中间部分界定序列中其他请求的寻道时间，这等同于在最坏情况下请求被平均分发到磁盘上的总寻道时间。缓冲器大小由数据块大小 Bi和调度方法确定。例如，对于可变比特率情况下，它是用于轮循调度块大小的
20、两倍：对于一块用于磁盘请求，另一块用于在循环期间所使用的数据流设备的缓冲数据。对于单次扫描调度所需的缓冲器大小是块大小的三倍， 由于对请求重新排序，第三块是必需的。循环周期在磁盘调度程序的初始化期间被选择。使用较大的循环周期能降低一个周期内相关的切换开销，但需要更多的存储器。它还会影响用户操作的响应时间。最坏情况下的响应次数上升，但平均响应时间的效果却不太明显并依赖于几个因素。C.非实时请求在我们的解决方案中，非实时请求来自 RTFS 和传统 FS。这些请求被用来更新文件系统管理信息，支持非实时应用，如内容浏览，管理元数据数据库，并支持任意的第三方应用程序。系统设计者对何时以及发出多少非实时请
21、求毫无认识与控制权。1)使用松散时间非实时请求的处理视一个周期中 RTFS 的松散时间而定。松散时间是不包括用于流的空闲时间。因此，非实时请求对流性能没有影响。松散时间是有的因为流失请求的时间通常比预定时间花费得少，这是在许可控制期间由最大流比特率和开销上界 SW(n)计算出来的。在实际中 RTFS 没有必要为非实时请求保留一定的磁盘吞吐量。所有来自传统 FS 的磁盘请求都由调度程序将其作为非实时请求来处理。结果是，磁盘的随机传统应用程序请求在没有破坏流实时保证下被处理。2)拆分非实时请求RTFS 调度程序能够在几个周期内拆分和完成一个非实时请求，因为请求的大小可能会过大以至于不适合在一个周期
22、的空闲时间中完成。请求大小比如第三方应用的请求，实际上对于整个周期来说会过大，因为设计者从来不知道彼此的需求。3)重新排序非实时请求重新排序非实时请求对于寻道优化是有利的。但这并不总是被允许的，因为重新排序会由于如电源故障而产生不一致。因为这样，RTFS 不能对传统文件系统上的请求重新排序。值得注意的是，在录制期间对请求进行重新排序对于流的时移和播放来说并不是问题。在录制请求完成之前，这个数据块并不是这个文件的一部分，因此播放是不能对读取该块发出指令。IV. 可扩展性不论出于何种原因，无论是更高的性能、更低的成本、新功能或更多功能，可扩展性对于 HDD 录像机和家庭媒体服务器在磁盘类型、流的需
23、求和非实时吞吐量等方面变得愈发重要。A.HDD 类型与模式不同类型的磁盘驱动器的性能由于不同的旋转速度、寻道时间、媒体几何形状和外形如 1/1.8/2.5/3.5 英尺而有所不同。利用由测量产生的磁盘性能模型，该系统都能在使用一个不同的磁盘时或磁盘性能随时间劣化时适应于磁盘性能的变化。在我们的解决方案中，不同的磁盘性能模型可以在设计阶段或运行时被提取。当不同的磁盘被连接时，系统软件是不需要被改变的。一台 CE 设备被期望保持其运作噪声水平足够低以保持在卧室或起居室内不显眼。主流的 HDD 通常有两种运作模式：正常模式下与在 PC 中具有同样性能，而另一种静音模式具有降低寻道性能并且更加安静。我
24、们的性能模型对两种模式使用不同参数，它可以根据优选的磁盘配置在运行时切换到正确的一组参数。磁盘性能可能因磨损和环境变化（如高温）而随时间恶化。我们的解决方案允许使用性能监视器来更新性能模型。以这样的方式，系统可以按照环境变化和性能的劣化情况，并且还提供最好保证流。B.不同的流典型的 HDD 录制解决方案是为固定流需求如固定比特率的固定数目流实现的。这可能需要完成切换到不同流媒体需求的重新设计。1)不同的流不同的视音频流对于家庭媒体服务器来说是很有趣的，如各种 MEPG2 格式的 SDTV流（10Mbps ）、MPEG2 格式的 HDTV 流（20Mbps）和从非常低比特率（1Mbps）到高比特
25、率的 MPEG4 视频流。音频流具有更低的比特率（20Kbps）并且在非实时模式下被处理。2)许可控制RTFS 通过使用许可控制机制来实现应用灵活性。新的各种比特率的流可以在运行时由应用程序被允许进入。许可控制协商需要以下几个步骤：1、检查可调度性：首先，应用程序请求 RTFS 一个新的流是否在保证比特率下可调度。如果可调度，RTFS 调度程序会计算流块大小和缓冲区大小，并把它们返回到 FS 层和应用程序中。2、准备流：当应用程序接收这些参数，它会创建一个流缓冲区，并将其链接到流媒体设备。3、启动流：然后应用程序请求 RTFS 启动流。RTFS 在此检查可调度性，并将流添加到调度程序中，一个流
26、开始启动。3)解决方案的可调度性在最坏的情况下，如完整的文件系统碎片化，我们的解决方案可以同时处理，例如一块 3.5 英寸主流的 IDE 磁盘上的四个 HDTV（20 Mbps）的数据流和四个SDTV（ 10Mbps ）流在。C.非实时吞吐量除了保证流的吞吐量，解决方案对在非实时模式下 HDD 访问应用程序没有限制。此外，它还优化非实时访问的性能。1)使用最大适应时间在许多流的解决方案中，由调度方案为非实时请求分配的吞吐量被固定在设计中。造我们的方案中调度程序能够为非实时请求使用所有的松散时间。在相同的流负载下，非实时请求的吞吐量比在固定情况下要高。2)非实时请求优先化RTFS 调度程序对非实
27、时请求有几个优先级，具有较高优先级的请求较早被服务。例如，更新文件系统管理信息使用最高优先级，以减少数据丢失的可能性，而背景缺陷检测可以用最低的优先级，以为用户操作例如，更新文件系统管理信息使用最高优先级，以减少数据丢失的可能性，而背景缺陷检测可以用最低的，以增加带宽为用户操作。优先级可以对最重要的事情帮助使用有限的资源，诸如磁盘带宽和在移动的情况下的力量。3)传统 FS以 RTFS 从传统文件系统如 Linux、WinCE 和其他操作系统处理磁盘的方式的不同方法是可能的。一个好的解决方案应允许系统在 HDD 上进行启动和虚拟内存。一种方法是将传统 FS 的 HDD 驱动器调用重定向到 RTF
28、S 调度程序中。如果明确和可用的驱动接口能被找到的话，这是一种简单的方法。但其缺点是，如传统 FS 请求的吞吐量可能会减少。这是因为该请求是在硬盘驱动器级同步处理，并且调度程序在一个周期中只能调度一个请求。对于像 Linux 复杂的文件系统，重定向驱动接口到 RTFS 是很困难的，因为在 Linux内核中复杂的存储器管理和设备管理是复杂的。我们找到一种方法将 RTFS 加载到内核中，这个加载方式能够从内核发送带请求列表的快照到 RTFS 调度程序中。接着调度程序决定哪个 Linux 请求在没有流保证影响下被执行。尽管这不是一个非常完全的解决方案，但它能使 RTFS 代码高度独立于操作系统并提供
29、良好的性能。有了这个解决方案，我们可以在同一磁盘上录制和播放 12 个 DVB 流的同时运行Linux 程序如 Netscape 网络浏览器和编译整个内核。4)提升非实时性能通常来说一个应用程序同步地发出非实时磁盘请求：当一个完成时，下一个会被发出。而且通常应用程序只在某些时刻发出非实时请求。但是，当它需要磁盘访问时，它要充足的吞吐量，这同样适用于用户。这是一个好主意去尝试为非实时请求创建一个大时隙，因为非实时有断点表现。例如，在完成一个预定请求序列后，调度程序仅仅为非实时请求使用这个周期的剩余时间。以这样的方式，尽管在部分时间里，非实时请求得到完整的 HDD 带宽。创建用于非实时请求的大时隙
30、并不与减少用户相应时间的方法相冲突，这是调度程序在前一个结束后立即启动新周期的原因。用户操作通常与非实时磁盘请求相关，如改变菜单或浏览内容信息。这些操作一般用这种方式能更快地被处理。.实现与结果我们的解决方案除传统 FS 链路外都是独立于操作系统的。实现使用一个小型操作系统抽象层，包括内存分配，信号量，消息队列等等。第一个 RTFS 版本是在嵌入式操作系统 pSOS 上实现的。后来的版本基本上还是独立于操作系统，但是在 Linux 用户空间上进行开发。该解决方案的一个示例为具有一个 IDE 硬盘的 Linux PC，这台 PC 具有一个 350MHz奔腾 II 处理器。主流磁盘包含一个视音频流
31、的 RTFS 分区和正常 PC 功能的 Linux 分区。专用 PCI 卡用于 DVB 输入，以及用于解码视频。一个 2.4 倍写入速度 DVD+ RW 驱动器连接到第二个 IDE 控制器作为 DVD 档案管理器。我们在示例中运行的流媒体应用是多个在磁盘上同时录制 DVB 广播信道和回放录音的时间转换器。同时，我们运行各种 Linux 的功能：从互联网浏览软件开发。我们还使用开源软件运行 DVD 存档功能，其从一个用户在 HDD 上选取的录制文件创建一个 DVD 视频镜像和用 DVD+RW 驱动器烧录 DVD 光盘。该解决方案能够使用一个主流 3.5 英寸 IDE 磁盘和周期为 600 毫秒的
32、单扫描调度程序同时处理 6 个独立的时间转换器或 12 个 DVB 流。在 4-10Mbps 范围的可变比特率的DVB 流在欧洲是典型的电视信道广播。每个流采用 1.4MB 的缓冲区，当 12 个 DVB 流访问磁盘，所有 Linux 功能依然正常工作。DVD 归档功能大致实时工作，不管是什么 Linux应用程序正在运行，时移视频流看起来很完美。用户还可以做花式功能，诸如暂停、快进、快退和切换直播等，尽管快进/快退不具有性能保证。使用 1 英寸磁盘，解决方案依然能同时处理 3 个 DVB 流。我们还测量流的吞吐量以及在一个 3.5 英寸主流 IDE 磁盘上具有不同流设置的 Linux应用程序。
33、这个磁盘具有 40GB 容量、7200 转的转速和 18.8MB/s 的持续比特率，它在32ms 全距离寻道时间的静音模式下工作，且其线性寻道时间模型偏移量为 14ms。这些流用于时间转换器，这些文件平均分发到 RTFS 分区中，占整个磁盘的 80%。Linux 应用程序的吞吐量是使用一个巨大持续的磁盘复制程序来测量的。需要注意的是，Linux 本身也会发出一些磁盘请求，但这些请求不被计算在吞吐量中。这些流具有可变比特率，导致在测量中造成较大变化，同时在实时与尽力之间的权衡也是清晰可见的。如表 1 所示，在 12 个 DVB 流的情况下，Linux 磁盘复制应用程序时仍然有至少1MB/s 的吞
34、吐量。表 1.流和 Linux 应用的测量吞吐量吞吐量随着流的数量减少或总的流比特率下降而增加。只需要较少的流吞吐量，非实时应用程序自动获得更高的吞吐量。流的总吞吐量和非实时请求量应随流的数量下降而增加。这是因为在一个大型连续的 Linux 磁盘复制操作情况下切换开销下降，但在测量中其基本保持不变。总吞吐量只有持续比特率的一半，这符合我们在 12 个流情况下的计算结果因为切换开销超过一个周期的 50%。当流的数量下降时，非实时请求吞吐量并没有充分利用。原因是调度程序一次只接收由 Linux 磁盘复制程序发出的大请求的一小部分（128KB ），并在新请求到达调度程序前花费一些时间，这样导致非实时吞吐量的损失。整个 12 流应用程序大致花费奔腾 II 处理器的 5%处理器负载。允许更少的流进入导致 PC 功能带宽逐渐增加，表明其可扩展性。类似的结果从其他所有主要 HDD 制造商的主流磁盘观察得出。.结论RTFS 使用像磁盘调度和文件分配管理技术调整组合。这就是磁盘独立，并且支持结合传统 PC 功能的多个实时视音频流。它能够为汇聚 CE 功能和诸如家庭媒体服务的进阶产品的 PC 功能提供可扩展的解决方案。
