一、iperf3工作原理

iperf3次要的性能是测试基于特定门路的带宽,在客户端和服务器端建设连贯(三次握手)后,客户端发送肯定大小的数据报并记下发送的工夫,或者客户端在肯定的工夫内发送数据并记下发送的总数据。带宽的大小等于发送的总数据除以发送的总工夫。对服务器端来说,在连贯建设工夫内,接管的总数据除以所花工夫即为服务器端所测得的带宽。

iperf3测试UDP的性能时,客户端能够指定UDP数据流的速率。客户端发送数据时,将依据客户提供的速率计算数据报发送之间的时延,客户还能够指定发送数据报的大小。每个发送的数据报蕴含一个ID号,用来惟一地标识该报文。服务器端则依据该ID号来确定数据报失落和乱序。当把UDP报文大小设置能够将整个报文放入IP层的包(packet)内时,那么UDP所测得的报文失落数据即为IP层包的失落数据。这提供了一个无效的测试包失落状况的办法。数据报传输提早抖动(Jitter)的测试由服务器端实现,客户发送的报文数据蕴含有发送工夫戳,服务器端依据该工夫信息和接管到报文的工夫戳来计算传输提早抖动。传输提早抖动反映传输过程中是否平滑。因为它是一个相对值,所以并不需要客户端和服务器端工夫同步。

由上介绍咱们能够晓得iperf3的性能减少了操作系统网络度量的能力,而携带Liteos_A内核的OpenAtom OpenHarmony(以下简称“OpenHarmony”)操作系统目前还不反对这个性能,特此尝试把iperf3移植到反对Liteos_A内核的OpenHarmony操作系统中,并作此文分享一些心得。

二、iperf3移植过程

iperf3能够运行在Linux和Windows平台下,其应用了规范的POSIX接口,因而将iperf3移植到Liteos_A上,目前Liteos_A反对用户态和内核态的命令,这个也造成了移植的很大艰难,所以以下将2种增加命令的形式都记录下,供读者参考。

  1. 确定库的类型
    OpenHarmony有如下几种指标类型:

executable: 生成可执行文件,对于Liteos_A,在目录/bin下能够找到可执行文件

shared_library: 生成.dll或.so动态链接库、对于Liteos_A,在目录/lib或者  /usr/lib下能够找到动静库

static_library: 生成.lib或.a动态链接库

group: 生成依赖关系组

action: 运行脚本以生成文件

依据以上几种类型的形容可知,将iperf3移植成executable类型的组件最为适合。

  1. 增加库到工程中

将源码下载到Linux下并解压,执行./configure,生成iperf_config.h,将iperf3的源码拷贝到OpenHarmony代码库中适合的地位,如下将iperf3增加到/third_party目录下。

须要留神的是非内核态的库不能增加到内核的目录下,不然编译和调试过程中相干的头文件可能找不到。在/vendor/厂商名/产品型号/config.json中的某一子系统下增加组件。

在 /build/lite/components/子系统名.json中增加组件,如下:

  1. 编写配置BUILD.gn

移植的iperf3代码目录下须要提供一个gn文件,指明须要编译的代码。此文件能够通过import组件模板函数。一方面,很多援用到的头文件须要一一增加到零碎BUILD.GN中去,import组件模板函数能够省去很多麻烦;另一方面,头文件有多个,最终还很难确定是哪一个,应用系统配置好的组件模板函数,能够主动匹配。

  1. 程序启动入口:将三方库增加到shell命令

1) 内核态的shell性能不合乎POSIX规范,仅供调试应用,本文特记录下其增加命令的办法,此办法分为动态和动静两种形式,增加形式如下:
① 命令源代码蕴含如下头文件

#include "shell.h"#include "shcmd.h"

② 动态注册命令形式

第一步:调用SHELLCMD_ENTRY(l, cmdType, cmdKey, paraNum, cmdHook),在源文件最初减少这个调用即可。

第二步:在链接选项中增加链接该新增命令项参数。
即在kernel/liteos_a/tools/build/mk/liteos_tables_ldflags.mk中减少相应选项,SHELLCMD_ENTRY的第一个参数前加-u。

此办法增加的shell,在代码编译阶段就已编译进去了,其实现原理是利用了编译器的section个性(也是代码模块化的重要伎俩),将所有shell命令相干性能都放在一段间断的地址空间,将SHELLCMD_ENTRY宏一层层开展,即可失去上面原型。

LOS_HAL_TABLE_BEGIN(g_shellcmd, shellcmd); //段的起始tagLOS_HAL_TABLE_END(g_shellcmdEnd, shellcmd); //段的完结tagSHELLCMD_ENTRY(l, cmdType, cmdKey, paraNum, cmdHook)

如下是编译后生成的map文件中shell段的局部,能够察看到曾经通过此办法退出的shell命令。

③ 动静注册命令方
式此类形式是在代码运行阶段动静的注册,osCmdReg自身是一个函数,在命令初始化的源代码减少此函数调用。

UINT32 osCmdReg(CmdT ype cmdType, CHAR *cmdKey, UINT32 paraNum, CmdCallBackFunc cmdProc)

函数原型在/kernel/liteos_a/shell/full/src/base/shcmd.c 能够找到,基本原理是将动静注册的shell命令退出到动静shell命令链表空间。

2)用户态的shell不必手动增加
增加指标的形式为executable,将程序下载到指标板上,在/bin目录下找到可执行的文件,只有在串口助手中输出 ./bin/可执行文件名,内核即可动静加载可执行的文件(或者输出exec  /bin/可执行文件名)。

三、iperf3应用形式介绍

应用iperf3测试时必须将一台主机设置为客户端,一台主机设置为服务器。在Linux环境或者Windows或者OpenHarmony shell交互窗口输出iperf3 -h能够获取iperf3的帮忙信息。以下介绍几种常见的应用形式:

  1. iperf3测试TCP
    在默认的状况下,iperf3客户端与指定的监听5201端口的iperf3服务器建设一个TCP会话。

    服务端:iperf3 -s客户端:iperf3 -c 服务器IP   (默认测试10秒),应用t来设置测试工夫,单位是秒。例如:iperf3 -c 192.168.99.74 -t 20

    运行后果如下:

  1. iperf3测试UDP
    iperf3测试UDP性能时,客户端能够指定UDP数据流的速率。客户端发送数据时,将依据客户端提供的速率计算数据报发送之间的时延。

客户端还能够指定发送数据报的大小。每个发送的数据报蕴含一个ID号,用来惟一标识报文,服务器端依据该ID号来确定数据报失落和乱序。

当把UDP报文大小设置能够将整个报文放入IP层的包(packet)内时,那么UDP所测得的报文失落数据即为IP层包的失落数据,这提供了一个无效的测试包失落状况的办法。

数据报传输提早抖动(Jitter)的测试由服务器端实现,客户发送的报文数据蕴含有发送工夫戳,服务器端依据该工夫信息和接管到报文的工夫戳来计算传输提早抖动。传输提早抖动反映传输过程中是否平滑。因为它是一个相对值,所以并不需要客户端和服务器端工夫同步。测试过程如下:

服务端:iperf3 -s -p 6868  (设定服务端监听6868端口)Liteos_A shell客户端:./bin/iperf3 -c 172.17.5.159 -p 6868 -u -b 100M

测试后果:

  • Jitter(延时变动):用iperf3 UDP测试来量度
  • 数据报失落:用iperf3 UDP测试来量度-
  • 带宽:通过TCP测试来量度
  1. 反向带宽测试
    服务端应用的命令不变,客户端须要加上参数-R,在帮忙信息中,能够看到-R的信息是run in reverse mode (server sends, client receives)

    服务端:iperf3 -s -p 6868客户端:./bin/iperf3 -c 172.17.5.159 -p 6868 -u -b 100M -R

    测试后果如下:

  1. 同步双向带宽测试
    客户端加上命令参数 -bidir

    服务端:iperf3 -s -p 6868客户端:./bin/iperf3 -c 172.17.5.159 -p 6868 -u -b 100M -bidir

    测试后果如下:

四、注意事项和遇到的问题及解决办法

  1. Hi3516有三种下载程序的形式:串口、USB、网口转USB。举荐应用USB来下载程序,应用串口来调试程序。
  2. DevEco Device Tool工具应用USB烧录Hi3516DV300镜像时失败,怎么解决?

解决措施:
呈现这个问题,次要是因为开发者将Device Tool工具装置在零碎盘符,在烧录大文件时会因为没有权限导致失败,能够依据以下操作解决:
● 在Windows平台找到装置目录,如图。鼠标右键,选中属性。
● 顺次操作,步骤5将红框中两个选项都勾选上。

  1. Hi3516如果携带操作系统是反对Linux内核的OpenHarmony,第一次下载时,须要格式化,下载实现后,系统启动到boot,就不会疏导整个零碎应用程序,这时须要点击如下菜单,而后从新拔插USB能力进入整个零碎。

  1. 在编写.gn文件时,如果三方组件为executable,那么第三方库代码中须要有惟一个入口main函数,最终生成一个可执行的命令。
  2. iperf有大版本1,2,3,目前最新的是iperf3,不同的版本间命令参数不同,工作机制有所不同,所以在测试时,服务端和客户端要求应用雷同的大版本。例如iperf3服务端不反对iperf的-u,-命令。
  3. 在应用iperf3进行测试过程中,须要敞开防火墙,不然可能不能进行失常测试,能够提前应用ping测试一下网络是否已通。
  4. 公司网络端的管制也会对测试造成影响,如果测试中发现发送和接管到的数据始终是0,则可能是网络管制端进行了管制,在拔掉外网络的状况,测试进去的后果就会很稳固。
  5. Hi3516主板作为服务端,输出iperf3 -s,而后在PC机上启动客户端进行测试,发现基本不能进行失常测试,起因也是公司网络管制导致,解决办法是将要测试的两个网络接口,接到同一交换机下,而后拔掉外网的网线,能够进行失常测试;或者须要IT开发权限,当然如果不是在公司特定网络环境下,这个景象是不会呈现的。
  6. Hi3516须要设置网络能力进行测试,能够应用命令ifconfig来设置,例如:ifconfig eth0 172.17.5.253 netmask 255.255.254.0 gateway 172.17.4.1
  7. MSS在OpenHarmony的底层LWIP不反对,在iperf_connect函数中调用getsockopt(test->ctrl_sck, IPPROTO_TCP, TCP_MAXSEG, &opt, &len),会通过零碎调用达到kernel层中的/kernel/liteos_a/compat/posix/src/socket.c, 最终走到底层LWIP的lwip_getsockopt_impl接口,在level IPPROTO_TCP下,对于分支TCP_MAXSEG,没有实现,解决办法是先屏蔽iperf3对此处的操作。同样在调用setsockopt(s, SOL_SOCKET, SO_SNDBUF, &opt, sizeof(opt))时,SO_SNDBUF分支在LWIP也未实现,先屏蔽此处,将发送缓冲区设置成和接收缓冲区同样的大小。
  8. Liteos_A未实现延时删除,所以调用unlink时会出错,目前解决是先屏蔽此处。
  9. Liteos_A对fprintf的实现也不如Linux,Windows好,所以对help命令输入到stdout上,长字串显示不进去,解决办法是应用fputs替换fprintf。

五、总结

本文从iperf3的工作原理、移植过程、应用形式、注意事项四个方面介绍了将iperf3移植到反对Liteos_A内核的OpenHarmony操作系统中的办法,心愿本篇文章对开发者有所帮忙。

对于OpenHarmony内核的内容,之前我还介绍了内核对象队列的算法、OpenHarmony LiteOS-M内核事件的运作机制,以及内核IPC机制数据结构,感兴趣的读者能够点击浏览:
《OpenHarmony——内核对象队列之算法详解(上)》、
《OpenHarmony——内核对象队列之算法详解(下)》、
《OpenHarmony——内核对象事件之源码详解》、
[《OpenHarmony——内核IPC机制数据结构解析》。
](https://mp.weixin.qq.com/s?__...)