有了这个话题，我会更好地讨论HR定时器和真正的精度问题。HR定时器精确度研究案例
我研究了大量有关它们的文档，我确信它们是在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分辨率下运行，但不幸的是，在我的系统中，我没有得到延迟低于6毫秒的预期结果（我将在稍后显示更多细节）。
我的环境是：
- 的Windows 10 PRO 64位/ 8GB内存/ CPU英特尔4个核
- 的VMware Player 12
虚拟化操作系统Linux Mint的18.1 64位
内核配置
- 版本：4.10.0-24-ge neric
- 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 => ts ÇHPET acpi_pm
/SYS /装置/系统/ clocksource/clocksource0/current_clocksource => TSC
要执行的基准我写了我自由在发布一个Linux内核模块网址https://bitbucket.org/DareDevilDev/hr-timers-tester/。在自述文件中有自己编译和运行的说明。
它执行一系列的循环如下：
- 10美国.. 90 US，增量通过美国10
- 100 US .. US 900，增量100美国
- 1毫秒。 9 ms，增量1 ms
- 10 ms .. 90 ms，增加10 ms
- 100 ms ..900毫秒，100毫秒
- 递增，并且最后1秒
的定时由“ktime_get”功能测量并存储在预先分配的阵列，更快的演出，并避免内部的不希望的延迟小时定时器回调。
收集数据后，模块打印出采样数据表。
对于我的情况的相关数据是：
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
...等等...
正如你可以在上面内核日志转储看，6毫秒是第预期延迟样本。
我在C.H.I.P.上重复了同样的测试。嵌入式系统（https://getchip.com/pages/chip），基于ARM的板载Raspberry，运行频率为1 GHz，并且配备了Ubuntu 14.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
...等等...
在那个便宜的主板了良好的效果，因为来美国300。
您的意见是？有没有更好的方法来以独立于平台的方式从HR计时器获得更高的精度？ HR定时器是精确定时的错误解决方案（必须在编写硬件驱动程序时使用）？
每个贡献将非常感激。
谢谢！