確定Linux上clock_gettime分辨率的正確方法

我正在處理作爲家庭作業一部分的Linux上定時分辨率的古老惡魔。長話短說，我試圖找到一種機制，可以在運行Linux版本2.6.32的英特爾i5四核3.2 GHz機器上給出最佳分辨率。確定Linux上clock_gettime分辨率的正確方法

我擡頭看着不同的方法，最後我比較了clock_gettime和RDTSC的表現。我可能會張貼後者另一個問題，但這裏是我做，找了clock_gettime調用所需的平均時間：

clock_gettime(CLOCK_MONOTONIC, &ts_start); 
for(loopindex = 0; loopindex < 1000000; loopindex++) 
    clock_gettime(CLOCK_MONOTONIC, &ts); 
clock_gettime(CLOCK_MONOTONIC, &ts_end);

ts, ts1, ts2是struct timespec型。我後來計算ts_end和ts_start之間的差值除以1000000.這給我26ns。

我當時以爲的其他嘗試一些：

clock_gettime(CLOCK_MONOTONIc, &ts1); 
ts2 = ts1; 
while(ts1.tv_sec == ts2.tv_sec && ts1.tv_nsec == ts2.tv_nsec) 
    clock_gettime(CLOCK_MONOTONIC, &ts2);

ts1和ts2再次是struct timespec型。我打印循環終止時的差異。現在，這給了我〜100ns。

我很困惑什麼是正確的做法，什麼是正確的價值。在時代應該如何解讀時，我是否缺少一些基本觀點？另外，這讓我對「決議」一詞感到困惑。 26ns/100ns是否表示系統上clock_gettime的實際分辨率是26ns/100ns？

編輯

我也各不相同的第一個方法的循環計數和使用更小的數字。第一次通話需要很長時間（〜140ns），第二次通話時間較長，直到它在所有後續通話中以26ns平均。我猜這是由於緩存。這會影響正確的價值嗎？

來源

2015-09-12 Cygnus

以平均值是絕對誤導。當你兩次讀取相同的值時，差值爲零，並降低平均值。所以我會說100nsec是兩個值中更正確的。我通常運行第二個循環數千次，保持直方圖的差異。預計每個差異將是決議的倍數。 – user3386109

@ user3386109：糟糕，我犯了一個錯誤 - 第一種方法不同。請再次檢查問題。 – Cygnus

第一種方法是測量調用'clock_gettime'函數所花費的時間。這是一條重要的信息，因爲可能的調用函數時間大於時鐘分辨率。在這種情況下，確定時鐘分辨率會更困難。但是，該循環不會告訴您關於時鐘分辨率的任何信息。它只告訴你，調用'clock_gettime'大約需要26nsec。 – user3386109

知道內部時鐘分辨率的最佳方法是使用函數clock_getres(2)，如posix中所述。

int clock_getres(clockid_t clk_id, struct timespec *res);

來源

2015-09-14 09:00:21

確定Linux上clock_gettime分辨率的正確方法

回答

相關問題