On Fri, Sep 20, 2024 at 1:21 AM Stephen Hemminger <step...@networkplumber.org> wrote: > > On Thu, 19 Sep 2024 01:04:40 +0300 > Isaac Boukris <ibouk...@gmail.com> wrote: > > > Hi, > > > > On Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz (see lscpu output at the end). > > > > The rte_get_tsc_hz() returns 2100000 KHz but using it causes our > > timestamps to lag behind real time (roughly a sec per 10 min). I > > noticed the kernel uses 2095082 KHz and in fact it gives much better > > results. > > > > dmesg: > > tsc: Detected 2095.082 MHz processor > > > > tsc_freq_khz (custom kmod to exposes kernel's tsc_khz): > > cat /sys/devices/system/cpu/cpu0/tsc_freq_khz > > 2095082 > > > Sigh. exposing tsc frequency through sysfs is a Redhat extension > that never got merged upstream.
Actually I think it is a google thing, I got it from github, someone implemented it for all (hence custom). It is a shame it was never merged as people know about it for a long time. I mean the whole rdtsc API is incomplete without it. As it is, I think the low hanging fruit for now would be to: - lower the rounding in our linux estimate from 10 to 1 MHz. - ignore the arch result if the cpu doesn't have the tsc_known_freq flag. On top of that we can consider: - increase the time of our linux estimate code and lower the rounding even further. - lower the rounding of our common estimation code from 10 to 1 MHz.
