Bug 959
Summary: | tsc hz not matching kernel reported tcs frequency | ||
---|---|---|---|
Product: | DPDK | Reporter: | Maria Lingemark (maria.lingemark) |
Component: | core | Assignee: | dev |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | mb |
Priority: | Normal | ||
Version: | 21.11 | ||
Target Milestone: | --- | ||
Hardware: | x86 | ||
OS: | Linux |
Description
Maria Lingemark
2022-03-16 13:58:18 CET
This is probably a Linux kernel problem. I have an old AMD APU motherboard where the kernel's initial clock calibration function (which uses the PIT as reference) sometimes gets the CPU frequency slightly wrong. We found out that kernel's calibration routine in tsc.c very quickly times out, and accepts quite a lot of inaccuracy - at least in older kernel versions. If possible, could you compare to an external reference clock, to tell which of the two clocks are wrong (clock_gettime or tsc_time)? Let the test run for an hour, and compare to your wrist watch. 2.3 permille is 8 seconds per hour. PS: I assume you are using CLOCK_MONOTONIC_RAW, so your results are not affected by NTP or similar. (In reply to Morten Brørup from comment #1) > This is probably a Linux kernel problem. I have an old AMD APU motherboard > where the kernel's initial clock calibration function (which uses the PIT as > reference) sometimes gets the CPU frequency slightly wrong. We found out > that kernel's calibration routine in tsc.c very quickly times out, and > accepts quite a lot of inaccuracy - at least in older kernel versions. > > If possible, could you compare to an external reference clock, to tell which > of the two clocks are wrong (clock_gettime or tsc_time)? Let the test run > for an hour, and compare to your wrist watch. 2.3 permille is 8 seconds per > hour. > > PS: I assume you are using CLOCK_MONOTONIC_RAW, so your results are not > affected by NTP or similar. We did a test, running for 30 minutes with a phone stopwatch. clock_gettime=1800000060 us, tsc_time=1795773149 us, diff=4226911 us Phone time: 30.00.25 Which points to clock_gettime being the correct time. This test was done with CLOCK_MONOTONIC, but we have done the shorter tests with both CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW with the same results. |