七号信令网中多板卡适配器系统的设计与实现

0 引言

七号信令系统是现代通信网的关键技术之一，是电信网三大支撑网之一，是发展综合业务、智能网业务以及新业务的必备条件。它具备信令容量大、传送速度快的优点。目前七号信令网真正成为了电信网的神经网和支撑网。网络规模的扩大使得业务数量和种类逐增多，在这种环境下数据分析成为了抓住用户趋势的重要工作，而数据采集是各种数据分析的首要步骤，然而核心网的链路类型各异，用于接收数据的网卡种类多，各网卡的工作模式也不尽相同。在开发此类软件系统时，如果每生产出一个板卡就要修改大量代码，就要求开发人员同时关心已存在的各个板卡的加载存取技术，同时某一模块的错误也可能会导致整个系统无法运行。各类网卡的接口信息交互方式与数据结构各不相同，缺乏公开、统一化的通用接口标准，这使得开发和维护的难度以及压力大大增加。因此，设计一个通用的、具有较好灵活性的和扩展性的异构终端管理接口成为板卡统一管理的重要内容。

1 系统概述

1.1 系统设计架构

多板卡适配系统的设计架构如图 1所示。上层应用端通过统一接口访问多板卡适配器系统，获取数据流，开发过程比较简单。但是大多数板卡适配器都没有进行高速板卡和低速板卡混用的设计[12]，在多个上层客户端访问多板卡的情况下，就需要从驱动区到Linux内核再到软件系统缓存的拷贝，这样，低速板卡由于要与高速板卡抢占资源，传输效率受到了极大的障碍，容易产生单点瓶颈，并且直传输的延时大大超过了监测系统要求的精准度[13-23]。

通信网中存在的大量数据流对系统的实时性和稳定性要求比较高，因此设计数据传输时，解决高速板卡的数据传输速度瓶颈及处理延时问题是要解决的关键问题[24-34]。本文采用低速卡缓存、高速卡内存映射的设计，一方面降低传输延时，另一方面了解决了低速板卡与高速板卡对系统的占用导致的丢包现象，加强了系统的准确性和可靠性。

图1 多板卡适配器系统设计架构
Fig. 1 Architecture of Adapter Manager

1.2 现有数据捕获方式的不足

1.2.1 普通板卡环形队列缓冲方案的限制

对于现有的环形缓冲队列，当缓冲内容饱和时，如果不进行容量扩充，后续进入的数据将因为无法存入队列而被丢弃；如果临时进行扩充，如遇到长时间传输流量走低，扩充的那部分资源则被浪费，如果对这些内存进行再回收，会导致大量碎片产生。环形队列相对于普通队列虽然有防止假上溢的优点，但是它自身也存在一定的局限性。对于环形队列选取长度大小是内存管理成功与否的关键因素之一。如果队列的长度过短，则缓冲区很同意被读取的数据迅速充满；如果队列的长度过大，则造成资源的浪费。由于操作系统的内存资源宝贵，堆空间无法承载过多的待处理数据，也会造成有很多零碎的空余存储空间，而大容量需求的任务得不到资源。因此已有的环形缓冲队列已经不能满足链路速率突发状况的需求，需要一个可以动态扩容的缓冲队列承担起数据传输的任务。

1.2.2 高速板卡数据拷贝过程过多

多板卡适配器系统从网卡驱动获取数据，网卡的设备驱动都是运行在Linux系统的服务器中，在Linux下的驱动程序中都有一个函数 init_module()，此函数在驱动程序装载时执行，主要负责完成硬件资源的查找、注册中断、注册设备等等。设备注册可以将设备和对设备的操作关联起来，这个函数集中的各个成员是上层应用程序对硬件的进行的各种操作的实现，其具体内容如下：

驱动程序的主要任务就是实现file_operation这个结构体中的各个成员函数。这种常规的处理过程给在数据传输上消耗了很多时间。在发包源设备产生巨大的数据量时，数据要从驱动层缓存向应用层拷贝，再进入应用层缓存，最后向存储设备拷贝，系统的吞吐量受到了严重的限制。对于高速板卡的数据采集，如果要保证数据的实时性接收，以现有的数据传输模型将数据一层层拷贝向上传输，很难达到需求的性能。

图2 内核空间到用户空间的数据拷贝
Fig. 2 Copy action from kernel to user space

1.2.3 高速板卡和低速板卡共同抢夺资源

当高速板卡和低速板卡一起参与数据传输时，由于读包机制是在轮询每一个板卡队列的同时，比较时间戳最小的包，将其放入Am的缓存，假设在某一个时间高速板卡以最大速率发包，会导致以下原因：

系统每次轮询时都会取高速板卡驱动队列的数据包，因为其大量数据包都比其它板卡队列的数据包在时间优先，这就不可避免地造成低速板卡阻塞，系统的实时性下降[35-38]。

以原来的数据传输模型来接收高速板卡的数据包，需要开辟大容量内存，否则过快过多的数据包一旦没有空间存储，就会被丢弃[39-42]。同时向上层软件传输数据包的速率一旦太慢，系统同样会出现空间不足而丢弃数据包的现象。

由此可见复制机制是造成数据传输瓶颈的关键性问题，如何改进复制的机制是本章的重点。

数据采集工作对系统的实时性要求很高，尤其是在加入高速板卡以适应现在的高速链路的网络环境中，因此必须研究出一种发法来解决高速办卡数据传输时的瓶颈问题。

2 数据传输模块的设计与实现

2.1 多板卡适配器系统的数据传输流程

为了防止卡间乱序，需要等待缓冲区里都有包才开始读取，如果某一块板卡已经启动，却没有发包源对其进行数据传输，系统会在一个等待时延后造出一个空包打入缓冲区。因此对系统设置一个等待时延(T1)来等待所有板卡收包，队单块板卡设置一个等待时延(T2)来判断板卡在此段时间是否有数据源要接收。上层APP在调用读包接口时其过程如下：

上层APP调用读包接口；

多板卡适配器系统响应调用，扫描每一块板卡，等待T2时间，如果没有包进入，造时间包打入缓冲区；

判断是否所有缓冲区都有数据或等待是否超时；

如果步骤2中判断结果为true，取时间戳最小的包，并返回其长度。重复执行步骤1；

如果步骤2中的判断结果为false，返回0值。上层APP视为此时无包，则会sleep一段时间，然后重复执行步骤1。

图3 数据传输流程
Fig. 3 Procedure of data transmission

2.2 普通板数据传输解决方案

2.2.1 缓冲队列的设计

在多板卡适配器系统中，每个设备板卡对应的缓冲队列都是循环队列。由于链路速率变化迅速，如果不对缓存队列进行扩充，则系统会因为没有足够的空间将获取到的数据包丢弃，造成丢包现象。如果临时对缓存区进行扩容，则如果系统长时间速率较低，造成资源浪费，这些在一个对实时性和准确性要求很高的系统里是无法容忍的。

对于普通板卡的缓冲机制优化，借鉴了slab分配器的思想。Slab分配器是Linux内核系统中按任务需求动态分配内存的一种方法。基于此思想，可以将普通板卡的缓冲队列设计成可以动态扩容的队列，且不必因存储空间频繁地创建于回收而造成时间和资源消耗。其具体思路如下：在数据传输时，当某一个板卡缓冲区的队列有空间不足的趋势，就从“备用存储区“借用一块预备内存；当流量预测算法预测出未来经过板卡的数据流流速有下降的趋势时，即此板卡的缓冲区已经不需要过大的缓冲区时，则将“借来”的缓冲空间换给备用缓冲区。

系统在各个板卡初始化的时候，提前初始化化一些存储空间，这一部分存储空间我们称其为“备用内存”。通过对 DMA机制中 DMA_ring的数据结构的研究[1]，本文设计了一个用于存放备用缓冲块的状态描述环状结构。如图4所示。

为了方便快速地访问这些备用的存储空间，系统创建了一个环形队列来存储指向每一块存储区的地址。每个存储空间都有一个包含四个内容的结点，它们分别是S(Status)用来描述当前缓冲区的状态，如果它所指向的存储空间处于空闲时，则S的值是Null，如果它已被一个缓存队列征用，则它的值是设备板卡再系统初始化时的唯一编号；A(Address)是指向缓冲区的指针；L(length)是备用缓存区的长度，N(next)是指向下一个节点的指针。

每当缓冲队列的空间不足时需要容量扩充[6]，通过环形队列的头指针可以快速地调用到需要的内存块，并将其指针指向需要扩充的队列的队尾，这一过程如下：

1)“备用存储空间”接收到系统需要扩容的信号。从其接入点开始依次遍历各个结点的Status值。

2) 找到第一个S的值为Null，即存储空间没有被征用的存储块后，在需要扩充的队列的中插入一个结点，将管理指针(这一部分将在稍后介绍)指向Address，同时将Status置成相应设备在系统中的唯一ID。

当经过系统的数据流预测出某一块设备板卡的缓存队列已不再需要太多的存储空间，则将多余的存储块从网卡设备的缓冲队列中拿下来，由“备用内存”队列将其回收。这一过程的具体步骤如下：

1) 对板卡缓冲管理队列上的各指针进行遍历，检查其 S状态，如果不为空则跳过，如果为空，则说明这块存储空间已经具备回收的条件。

2) 缓存队列管理队列中需要回收的存储区的结点中，Address置成NULL，随后删除此结点。

3) 将“备用缓存”中的Status重置为NULL。

需要注意的是，由于在分配备用缓存区块的时候，并没有断开这个缓存块与管理其的环形队列的联系，因此在2)中只需删除板卡缓冲区的管机结点即可。

利用这种方法，有效地解决了缓冲队列在扩容方面进退两难的问题。由于“备用存储空间“是在系统初始化的初期创建的，因此避免了在数据传输期间频繁的创建和回收所消耗的开销，同时也降低了碎片的产生。

图4 备用内存状态描述符环形结构
Fig. 4 structure of spare memory’s status

图5 缓冲管理环形队列寻址机制
Fig. 5 Adressing mechanism for buffer management queue

对于每一个网卡设备的缓冲区，也有一个缓冲管理队列，其主要结构如上图所示，由于此队列是用来管理被“借来“的存储块的，因此并没有在此队列中为板卡设备最初的缓冲区创建结点。每个结点有三个值，结点包括 Address,存储一个指向“外借”存储块的指针；Count值，每当有数据存入，就对其进行累加，当数据送往上层，对其及进行递减。当此值为空的时候，则表明此存储块中没有数据；Lock值，如果板卡设备的需要对多余的存储区进行回收，同时有一块存储区恰好为空时，则将其Lock置为True。防止再有数据进入，为存储区的回收做准备；Next域指向下一个节点。其在对备用存储的请求过程如下：

1) 通过预测算法预测到缓冲空间即将不足，向分配进程发送消息。

2) 当有备用存储区可以分配时，在管理队列中加入一个结点，其指针指向借来的存储块。Count值初始化为0，Lock置为False。

3) 在备用存储区回收时，其流程如下：

4) 遍历管理队列中的结点，检查其Count的值是否为0。找到第一个count为0的结点，将其Lock置位True。

5) 将Address置为NULL。

回收该备用存储区在管理队列上的结点。

这种缓冲区组织明显改善了数据传输的效率。系统使用两个入口指针(EntryPoint)分别指向备用缓冲区队列和缓冲区管理队列，方便系统反复快速地扩容当前空间不足的所有缓冲队列。在系统崩溃之前需要采取一些额预防措施。预防包括两个方面，即预测数据流量的变化趋势和维持可靠的队列长度。

小波变换的估计方法还能对给定观察尺度下业务的霍斯特系数的一致性给出定性分析。

2.2.2 数据流量预测

在系统崩溃之前需要采取一些额预防措施。预防包括两个方面，即预测数据流量的变化趋势和维持可靠的队列长度[7]。

数据流流速是随时间变化的数据，我们可以把一组流速看作一个时间序列，并对其进行建模分析。目前比较一致的意见是用hurst系数来表征业务流突发特性。当霍斯特指数在0.5到1 之间时，业务呈现正相关性，即hurst系数越大业务的突发程度越剧烈。反之，当霍斯特指数在0到0.5之间时，业务呈现负相关性，即hurst系数越小业务的突发程度越剧烈。当hurst指数为5时，表明过去的增量和将来无关。

利用小波分析方法，对于霍斯特系数一致性好的业务源进行多分辨率采样，不仅减少了业务计数过程的统计样本总量。

图6 低速板卡和高速板卡数据传输模型的比较
Fig. 6 Differences in models between low-speed and fast-speed cards

2.3 高速板卡数据传输解决方案

由于高速板卡的速度差异可能使系统内的其他板卡处于长时间阻塞状态，因此为过高速板卡专门设计一个逻辑模块用于数据传输。本系统采用内存映射的机制，减少了操作系统的干预过程，使用户层可以有更多的灵活性，并且有效地减少了消息在发送和接收处理过程中的数据拷贝。图给出了低速板卡和高速板卡传输模型的对比。

在低速板卡的数据传输模型中[11]，数据发送要经过系统核心到应用程序的拷贝，系统核心中消息的各种处理包括数据封装、顺序控制等，封装的报文分组发向通信网，再通过解析包头分发给各个板卡的缓冲队列，最后缓冲队列将受到的数据送往上层。而在本系统的高速板卡的通信模型中，系统可以直接从系统核心读取数据，在图中的通信域与发包源可以直接传递数据。网卡硬件的初始化和通信去的建立与维护功能由专门的驱动程序来负责。驱动程序作为核心进程，它建立了数据源与通信区的连接。减少了消息传递的环节，降低了数据传输的开销。

这里通信区是一块用户层和核心层共享的物理内存，它采由用户空间与核心系统共享内存的方法，避免了在不同系统空间之间多余的数据拷贝，通信区的事先就像缓存一样，用来存放用户数据和网络数据。通信区通过Linux系统调用mmap由系统的核心态映射到系统的用户态[2]，两者可以共同访问之。通信去种包括发送、接收和空闲三个队列。它们三个的数据结构如下：

三个队列中的buff_offset分别指向了各自缓冲区的偏移地址，这就保证了无论是核心态还是用户态都能将通信区看作自身存储的一部分来进行操作。

3 系统的设计与实现

3.1 需求分析

本系统主要实现了一种可以屏蔽多种板卡的异构性，并为上层应用实时传送数据的多板卡适配器系统，称作“Adapter Manager”。通过调研和分析[8]，发现当前分散的板卡适配器系统存在如下问题：

(1)板卡驱动的加载、数据提取、转换、传输等过程比较繁琐，有些功能的自动化还没有实现，很多需要人工干预来完成。

(2)目前投入使用的板卡类型种类繁多，板卡间的功能既有重复，又有很多不同。

(3)由于多板卡的并行传输，且板卡间的传输速率相差很大，很容易造成低速板卡阻塞，高速板卡也经常遇到速度瓶颈问题。

基于以上的调查结果，多板卡适配器系统的总体需求如下：

3.1.1 功能需求

1. 系统可以在需要的时候动态地加载板卡。

2. 系统可以自动扫描链路，从而完成板卡的链路配置。

3. 能够根据业务需求准确过滤特殊帧。差错检出功能：具有中间层的告警功能；能够对数据帧的错误进行检测；能够对链路的可用状态进行检测；利用此功能可以检测链路类型。

4. 可以采集来自异构板卡的板卡信息、实时链路信息和数据传输过程中的详细内容。能对不同板卡的实时数据流量进行跟踪显

5. 具有链路注册和启用，以及控制驱动程序发包的功能。

6. 具有存储数据包的功能。多板卡适配器实时存储来自ThumbE1、Cpos622等低速板卡的接收到的数据包，可以提供灵活的存储方式(包括循环历史记录、定时自动记录等方式)。

7. 能够将驱动程序送上来的数据包传输给上层应用。

8. 系统可以提供运行时的日志。

3.1.2 性能需求

1. 系统无关性，可以在Linux和Windows的操作系统上运行。

2. 设备无关性，软件不依赖任何一个设备的存在就应该可以使用。

3. 能同时支持单个板卡和多块异构板卡的数据传输。

4. 多进程并发：多个不同应用程序可同时使用此适配器系统，且并不互相影响。

5. 在从驱动向上层应用传递数据时，尽量保证低丢包率、错包率，必须保证有序传送和实时传送。

3.2 系统组成

基于以上的缓冲机制优化与需求分析，图4-3给出了系统在完成缓冲区优化以后各模块间的联系。

适配器系统主要由三个模块组成：驱动加载模块、功能实现模块、数据传输模块。

1. 界面模块：主要负责显示设备列表、显示设备状态信息和配置信息的以及配置界面的呈现等。界面模块动态加载每个设备模块的 UI部分，然后按照用户选择的设备，显示它的详细信息。

2. 数据模块：数据模块管理各个设备对象，对不同的设备提取统一的接口，以便于外部访问。数据的主要接口有：设备信息遍历接口，链路配置的保存和读取接口，数据的读取接口，数据的发送接口。

3. 设备模块：设备模块主要是与和具体设备相关的部分； 它主要由一个设备对象类、一个设备管理类和一个设备UI构成；

(1)设备对象类是为每一个设备所创建的，记录了该设备属性信息和配置信息。同时也对软件提供访问该设备的方法，包括收发数据包/读取告警统计信息等。

(2)设备管理类统一管理同类设备的不同对象，以便于外部使用方便。

(3)设备由一个或一组对话框页面构成，以图形的方式来呈现此设备的属性信息和配置信息。同时提供更改属性和配置的方法，用户可以直接在上边操作就能修改设备的状态。设备UI被界面模块(XAdapterUI)所使用，呈现时作为总体界面的一个子窗口。更改配置时直接与设备对象类交互。

图7 多板卡适配器系统总体结构设计

3.3 系统的交互流程

上层数据分析软件通过”Adapter Manager”的界面模块来配置链路，通过数据模块访问数据，通过直接访问设备模块来访问链路信息，流程图如图8。

图8 多板卡适配器系统消息交互流程
Fig. 8 Communication in Adpter Manage

设备管理模块的处理对象是各种不同种类的网卡，每个板卡类型都有许多功能。如果针对不同网卡单独处理，必然导致很大的开销。本系统的设备管理模块的设计原则是将不同模块的共性剥离出来，集中处理统一的流程部分，而对于异构模块之间的差异做单独处理。因此，可以把共有的功能提出来作为一个单独的模块，每一个板卡类型再对应一个私有的类结构。这样即体现出所有异构板卡的共性和特性，又增加了结构的简洁性，更易于后期维护，更减少了物理内存。

3.4 设备模块功能设计板卡

3.4.1 链路扫描模块

1) 对2M与64K链路进行扫描

在数据通信的数据链路层都以帧的方式传递数据，为了对数据传输中产生的错误进行校验，每个传输帧中都带有帧校验序列FCS[3]。在链路扫描的过程中，根据不同类型的链路中帧校验序列的不同来区分链路。2Mbit/s高速信令链路与64Kbit/s信令链路协议上的主要区别就在信令链路功能级。根据2M链路和64K链路的信令单元格式不同来进行链路区分，以下是2M与64K信令格式的差异。

链路扫描在目前还不支持N*64k，因为扫描的最最小粒度是64k，因此如果预期是一条64K链路，则有且只有一种可能；如果预期是2M链路，也就是所有的64k子链路都被占满，因此此时也有且只有一种可能；当预期链路是N*64k，组合的方式就不止一种，没办法匹配出是哪几条链路进行了捆绑。因此在只有2M与64k能由链路扫描来检验。

表1 2 M与64K信令单元格式的差异
Tab. 1 Difference between Signal unit format of 2M and 64K

2) 对IMA链路进行扫描

IMA是多条链路的捆绑，最多有32条。在IMA组中根据IMA组中E1链路上所携带的ICP信元内容[9]，自动完成IMA的识别和配置。同一个IMA组里的链路都有唯一的链路逻辑信号，同一个IMA组里的协议必须一致，但是不同IMA组里IMA_ID允许一样。如下图所示给出了基于扫描单元和扫描索引对IMA组的捆绑进行猜测的流程。

3.4.2 特殊帧过滤模块

我国No. 7信令网采用三级结构, 第一级是高级信令转接点(HSTP),第二级是低级信令转接点(LSTP),第三级是信令点(SP)。在真实的网络状态下，由于链路状态和业务需求往往需要过滤到一种或多种类型的帧，保证检测结果的针对性和准确性。在本数据采集方案中，根据信令单元的来源不同，一共有三种类型的特殊帧[4]。它们分别是 FISU(填充信号单元)，MSU(消息信号单元)和 LSSU(链路状态信号单元)。其中LSSU是用来传输链路的告警和状态的，如果上层数据采层没有特殊的分析需求，可以将这一部分丢弃不要。对于FISU，只要链路为空或者故障时，就会用填充信号单元来填补，因此链路中的 FISU占的比例较多，因此将这部分过滤掉，会使数据传输的有效率更高，大大节省了带宽资源。

图9 M SU、LSSU、FISU信令单元帧头内容
Fig. 9 MSU, LSSU and FISU frame content

图10 数据包结构
Fig. 10 Content of data package

图11 数据包头内容
Fig. 11 Content of head information in data package

进行TUP信号测量时，如果对于MSU，在SIF中n的最大值为63。对于LSSU，Ll=1或2，对于FISU，Ll=0。因此通过比对 LI的长度，就可以过滤出FISU和LSSU。

当帧过滤模式打开时，进行TUP信号测量时，如果对于 MSU，在 SIF中 n的最大值为63。对于LSSU，Ll=1或 2，对于 FISU，Ll=0。因此通过比对LI的长度，就可以过滤出FISU和LSSU。

3.4.3 包头统一封装模块

为了屏蔽底层硬件的差异性，本系统将获取的数据封装统一的包头后再传递出去，系统输出的数据包的结构如图10。

包头为26个字节，其各字段含义如图11。(有些字段在不同类型的板卡里代表的含义不同)

3.4.4 网卡流量监测

可以采集来自异构板卡的板卡信息、实时链路信息和数据传输过程中的详细内容。能对不同板卡的实时数据流量进行跟踪显。通过调用ioctl函数来与驱动建立连接[5]，借助设备状态结构体_ZCNetDeviceStats将板卡的实时信息从驱动层向上层传递。Ioctl是备驱动中对设备的I/O通道进行管理的函数[10]，它可以根据网卡的设备文件名快速获取所需要的实时数据传输信息。_ZCNetDeviceStats的定义如下：

Ioctl通过网卡的设备文件名找到该板卡后，将所需数据复制到ZCNetDeviceStats中，提交给输出模块。由此本系统可以统计到网卡包括接受和发送的数据包、字节总数、错包个数和丢弃个数，以及网络的连通状态。

4 实验分析及测试结果

为了验证本系统的优化效果，本文通过对多种类型多块板卡进行抓包，并同时使用光口和电口，测试在大流量数据和小流量数据并存时系统的实时性和、准确性和稳定性。

本系统的测试环境如图 10所示，本系统的的设计主要是在监测系统中，为上层应用和底层驱动建立一个可以通信的中间层[6]。此监测系统分为接入层、采集层、应用/处理层和呈现层。以下是对于各层的简介：

图12 多板卡适配器的测试环境
Fig. 12 Testing environment of Adapter Manager

(1)数据接入层：实现不同链路的接入；

(2)数据采集层：实现不同数据业务相关监测接口的信令协议汇聚和采集；对呼叫详细记录进行关联合成，同时保存了原始数据信息；

(3)数据处理层：负责处理由数据传输屋送来的详细记录的合成记录，对记录中的各种失败原因、释放原因等指标进行分析,生成相应的优化统计分析报表；

(4)数据应用层：利用客户端软件对数据信息分别进行直观统计和分析；

(5)数据存储区域网络：将处理所得的数据按周期存储。

4.1 优化测试

在对本系统的普通板卡的缓存队列优化后，与优化之前的测试结果进行比较，在此测试用例中主要统计的指标有：

表2 缓冲区优化前后系统性能测试结果
Tab. 2 Testing result of system performance between and after buffer optimization

4.2 可靠性测试

多板卡适配器在数据传输性能的可靠性测试主要是看系统传输过程中随着并发板卡的不断增加和数据流量的不断加大丢包率变化情况。并发板卡数量和丢包率关系如表2所示。

表3 多板卡适配器下单种板卡和多种板卡的测试结果
Tab. 3 Testing result of single card and multiple cards in Adpter Manager

由表一可知，将单个板卡的测试结果和将测试过的板卡组合在一起的测试结果进行比较，后者的丢包现象基本等同于前者的和，因此本系随着并发板卡的增加，丢包现象并没有明显增大，丢包率也没有显著增加；长时间对单个板卡进行数据采集，可以观察到虽然有丢包，但长时间的丢包率趋于稳定，在系统可以忍受的误差范围内。

4.3 特殊帧测试

在FISU帧与LSSU帧过滤测试时，主要在发送数据中加入包含特殊帧的包，在终端检测此功能开启或关闭时的接收结果。为防止误差可接受范围内的丢包可能带来的影响，在测试时选择小流量近距离发包，基本不会发生丢包现象。

表4 多板卡适配器下特殊帧过滤的测试结果
Tab. 4 Testing result of special frame filter in Adpter Manager

由表2可验证，当过滤帧功能关闭时，适配器系统无条件接受所有帧。当过滤帧功开启时，系统能准确过滤掉条件所指的特殊帧。

5 结论

本文给出了多板卡适配器系统的设计方案，屏蔽了多种异构板卡间的差异性，统一了数据传输接口，并优化了系统的传输设计模型，解决了低速板卡与高速板卡共同工作时所遇到的传输瓶颈问题，实现了在检测系统中所需的过滤特殊帧、远程扫描链路进行链路配置等功能。并通过实际测试验证了优化效果。同时也证明了链路配置的准确性，收包的实时和有序性，这减少了新增板卡可能给整个检测系统带了的工作负担，简化了上层分析人员的收包流程，提升了整个监测工作的效率，具有较高的现实意义。