Cyclictest 是 rt-tests 下的一个测试工具，也是rt-tests 下使用最广泛的测试工具，一般主要用来测试使用内核的延迟，从而判断内核的实时性。
Debian / Ubuntu 系统下可以直接使用apt-get install rt-tests 来安装cyclictest。
使用Linux最大的好处就是我们可以下载软件的源码，学习、编译以及使用，所以如果使用上述方法直接安装使用，如果你觉得有的问题不懂或者出现问题你也没办法解决，所以从开发者的角度而言，下载安装软件还是下载源码包编译后使用比较好。
（1） 首先拷贝cyclictest的Git 仓库
# git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git
（2） 进入git仓库
# cd rt-tests
（3）创建一个分支，比如我们起名叫testing
# git branch testing
（4）转到testing分支，之后我们做的步骤都不会对主分支有影响，这是我们在电脑上使用 git 仓库的常用方法
# git checkout testing
（5）查看我们当前在哪个分支
# git branch
master
* testing
（6）在次我们使用make编译
# make
编译时我们会遇到缺失numa.h 的错误提示，在此我建议童鞋们安装使用apt-file 来解决此类错误（有了apt-file,遇到这类错误我们就知道如何解决而不是一味的上网找别人的解决方法），主要步骤如下：
# sudo apt-get install apt-file // 安装apt-file
# apt-file update // 类似于apt-get ,apt-file也需要根据系统配的源来更新一个库
# apt-file search numa.h // 使用apt-file search 搜索我们缺失的文件
libhwloc-dev: /usr/include/hwloc/linux-libnuma.h
libnuma-dev: /usr/include/numa.h // 在搜索到的结果中，我们发现这个包叫做 libnuma-dev 应该就是我们需要安装的包
linux-headers-3.2.0-4-amd64: /usr/src/linux-headers-3.2.0-4-amd64/include/config/acpi/numa.h
linux-headers-3.2.0-4-amd64: /usr/src/linux-headers-3.2.0-4-amd64/include/config/amd/numa.h
....
# apt-get install libnuma-dev // 使用apt-get 安装libnuma-dev 包
2. cyclictest 的使用及参数简介
对于Cyclictest的使用我们得先了解它的各个参数的含义，所以在你开始使用之前，请你看一下 cyclictest --help 中提到的各个参数！这将对你使用有很大的帮助。
如果你只是想玩玩这个工具，那么对于维基主页上提到的tglx 使用的测试命令来测测你的电脑性能：
# sudo ./cyclictest -t1 -p 80 -n -i 10000 -l 10000
注：在rt-tests的路径下，我们可以使用 ./cyclictest 来运行cyclictest, 而在别的目录下，我们就需要指定 cyclictest的路径来使用，比如说 /home/long/rt-tests/cyclictest ,或者你也可以直接将 rt-tests的路径下的 cyclictest 拷贝到 /bin/ 下，以后就可以直接使用 cyclictest 而不需要指定路径了！！
比如在我的电脑上，我使用这个命令测试的结果如下：
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.38 0.29 0.26 1/381 5595
T: 0 ( 5592) P:80 I:10000 C: 10000 Min: 2 Act: 15 Avg: 15 Max: 195
输出结果含义:
T: 0 序号为0的线程
P: 0 线程优先级为0
C: 9397 计数器。线程的时间间隔每达到一次，计数器加1
I: 1000 时间间隔为1000微秒(us)
Min: 最小延时(us)
Act: 最近一次的延时(us)
Avg：平均延时(us)
Max： 最大延时(us)
所以我们当前的机器上最小延时为2，平均为15，最大的为 195。
$uname -a // 我们可以使用 “ uname -a ” 看到我们系统目前使用的内核版本
Linux wheezy 3.2.51-trace #8 SMP Thu Nov 21 12:34:04 CST 2013 x86_64 GNU/Linux
$ cat /boot/config-3.2.51-trace |grep CONFIG_PREEMPT_RT // 我们再打开 /boot 下面的当前内核的config信息查看目前这个内核是否打上实时补丁，结果显示并没有。所以在一个普通的内核下测的 Min: 2 Act: 15 Avg: 15 Max: 195 这样的数据算是不错的了！
$ cat /boot/config-3.10.17-trace-rt12 |grep CONFIG_PREEMPT_RT // 而在我 /boot 目录下的另外一个打好实时补丁的内核中
CONFIG_PREEMPT_RT_BASE=y
# CONFIG_PREEMPT_RTB is not set
CONFIG_PREEMPT_RT_FULL=y // 判断一个内核是否是实时内核，请看config 下有没有此项
我得到的cyclictest 运行结果是这样的：
T: 0 ( 5592) P:80 I:10000 C: 10000 Min: 1 Act: 1 Avg: 2 Max: 9
.2 cyclictest 的参数介绍
-m --mlockall 锁定当前和将来的内存分配
-c CLOCK --clock=CLOCK 选择时钟 cyclictest -c 1
0 = CLOCK_MONOTONIC (默认)
1 = CLOCK_REALTIME
-i INTV --interval=INTV 基本线程间隔，默认为1000（单位为us），下面介绍原理的时候会提到
-l LOOPS --loops=LOOPS 循环的个数，默认为0（无穷个），与 -i 间隔数结合可大致算出整个测试的时间，比如 -i 1000 -l 1000000 ,总的循环时间为1000*1000000=1000000000 us =1000s ，所以大致为16分钟多。
-n --nanosleep 使用 clock_nanosleep
-h HISTNUM --histogram=US 在执行完后在标准输出设备上画出延迟的直方图（很多线程有相同的权限）US为最大的跟踪时间限制，这个在下面介绍实例时可以用到，结合gnuplot 可以画出我们测试的结果图。
-q --quiet 使用-q 参数运行时不打印信息，只在退出时打印概要内容，结合-h HISTNUM参数会在退出时打印HISTNUM 行统计信息以及一个总的概要信息。
-f --ftrace ftrace函数跟踪（通常与-b 配套使用，其实通常使用 -b 即可，不使用 -f ）
-b USEC --breaktrace=USEC 当延时大于USEC指定的值时，发送停止跟踪。USEC,单位为谬秒（us）。
2.3 推荐参数以及结果实例
一、测试命令./cyclictest –p 80 –t5 –n
1. 默认创建5个SCHED_FIFO策略的realtime线程，优先级80，运行周期是1000,1500,2000,2500,3000微秒，无干扰测试结果图：
由此可见在AdvLinux3.0.2实时系统，最小值在2~3微秒，平均值为9-11微秒，而最大值则分布在24-29微秒之间。
2.运行同样的测试，但是在运行这个测试的过程中引入更多的干扰，如将该设备与其它设备进行串口通信，则结果变为有干扰测试结果图：
引入串口通信过程，最大值为34us。没有出现AdvLinux3.0.2非实时系统下，最大值为1219微秒。
二、测试命令./cyclictest--smp -p95 -m
这一结果显示了Cyclictest工具运行在一个四核系统,在所有内存都锁定的情况下,每个内核运行一个测量线程,它们每一个SCHED_FIFO优先级是95，锁定内存分配。在测试的结果中,CPU0的最大延迟是33us,平均延迟是9us; CPU1的最大延迟是33us,平均延迟是9us; CPU2的最大延迟是32us,平均延迟是12us; CPU3的最大延迟是29us,平均延迟是13us.
cat /proc/cpuinfo查看系统是几核系统
三、测试命令./cyclictest -t1 -p 80 -n -i number -l10000
线程优先级为80，不同的时间间隔下的结果，其中，C：9397计数器。线程的时间间隔每达到一次，计数器加1
Min:最小时延（us）；Act:最近一次的时延（us）；Avg:平均时延（us）；Max: 最大时延（us）
I为500us时，最小延时为2，平均为11，最大的为 26。I为10000us时，最小延时为4，平均为17，最大的为 33。