人力资源定时器精度研究实例

Question

在这个主题下，我将更好地讨论人力资源定时器和真正的精确性问题。

我研究了大量关于它们的文档，并且我确信它们是解决linux内核模块内部延迟执行问题的最佳和最可靠的解决方案，CPU的成本更低，计时精度更高(例如，一些时间关键的驱动程序也使用它们，比如这个https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/pwm/gpio-pwm.c?rev=35328 )。

也适合你吗？

这里是我在这个主题上所见过的最全面和最详细的文档之一：https://www.landley.net/kdocs/ols/2006/ols2006v1-pages-333-346.pdf。

HR计时器承诺将执行jiffies决议，但不幸的是，在我的系统中，我没有得到延迟低于6ms的预期结果(稍后我会给出更多细节)。

我的环境是：

• Windows 10 PRO 64位/ 8Gb RAM / CPU Intel 4核
• VMWare播放器12
• 虚拟化操作系统Linux 18.1 64位
• 内核配置

- Version: 4.10.0-24-generic
- CONFIG\_HIGH\_RES\_TIMERS=y
- CONFIG\_POSIX\_TIMERS=y
- CONFIG\_NO\_HZ\_COMMON=y
- CONFIG\_NO\_HZ\_IDLE=y
- CONFIG\_NO\_HZ=y
- CONFIG\_HZ\_250=y
- CONFIG\_HZ=250
- /sys/devices/system/clocksource/clocksource0/available\_clocksource  => tsc hpet acpi\_pm
- /sys/devices/system/clocksource/clocksource0/current\_clocksource => tsc

​

为了进行基准测试，我编写了一个linux内核模块，我在url https://bitbucket.org/DareDevilDev/hr-timers-tester/上免费发布了这个模块。在自述文件中，有自己编译和运行它的说明。

它执行一系列循环如下：

• 10 uS .90 uS，增量10 uS
• 100 uS ..900 uS，增加100 uS
• 1毫秒。9毫秒，增加1毫秒
• 10毫秒。90 ms，增加10 ms
• 100毫秒。900毫秒，增加100毫秒
• 最后一秒

时间由"ktime_get“函数测量，并存储在预先分配的数组中，以提高性能，并避免hr计时器回调中不必要的延迟。

采集数据后，模块打印出采样数据表。

对于我的场景，相关数据如下：

   10 uS =      41082 nS
   20 uS =      23955 nS
   30 uS =     478361 nS
   40 uS =      27341 nS
   50 uS =     806875 nS
   60 uS =     139721 nS
   70 uS =     963793 nS
   80 uS =      39475 nS
   90 uS =     175736 nS
  100 uS =    1096272 nS
  200 uS =      10099 nS
  300 uS =     967644 nS
  400 uS =     999006 nS
  500 uS =    1025254 nS
  600 uS =    1125488 nS
  700 uS =     982296 nS
  800 uS =    1011911 nS
  900 uS =     978652 nS
 1000 uS =    1985231 nS
 2000 uS =    1984367 nS
 3000 uS =    2068547 nS
 4000 uS =    5000319 nS
 5000 uS =    4144947 nS
 6000 uS =    6047991 nS <= First expected delay!
 7000 uS =    6835180 nS
 8000 uS =    8057504 nS
 9000 uS =    9218573 nS
10000 uS =   10435313 nS

..。等等..。

正如您在上面的内核日志转储中所看到的，6ms是第一个预期的延迟示例。

我在我的C.H.I.P.嵌入式系统( https://getchip.com/pages/chip )上重复了同样的测试，这是一种基于ARM的板Raspberry，运行速度为1 GHz，配备了Ubuntu14.04(内核4.4.13，HZ = 200)。

在这种情况下，我得到了更好的结果：

  30 =      44666 nS
  40 =      24125 nS
  50 =      49208 nS
  60 =      60208 nS
  70 =      70042 nS
  80 =      78334 nS
  90 =      89708 nS
 100 =     126083 nS
 200 =     184917 nS
 300 =     302917 nS <= First expected delay!
 400 =     395000 nS
 500 =     515333 nS
 600 =     591583 nS
 700 =     697458 nS
 800 =     800875 nS
 900 =     900125 nS
1000 =    1013375 nS

...and等等..。

在那块便宜的板上，自从300 uS以来，就有了好的结果。

你有什么意见？是否有更好的方法从人力资源定时器获得更高精度的平台独立的方式？人力资源计时器是精确计时的错误解决方案(当我们必须编写硬件驱动程序时，这是强制性的)？

每一笔捐款都将不胜感激。

谢谢!

Answer 1

问题解决了，这是一个涉及虚拟化环境的问题。

在一台旧笔记本电脑(惠普单芯1.9GHz)上，我从60 uS起就得到了很好的延迟，而在较新的笔记本电脑(戴尔四芯)上，我的延迟却低于10 uS！