有了這個話題，我會更好地討論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定時器是精確定時的錯誤解決方案（必須在編寫硬件驅動程序時使用）？
每個貢獻將非常感激。
謝謝！