Re: Accuracy of rte_get_tsc_hz() compared to linux

[Isaac Boukris <iboukris@gmail.com>]

On Fri, Sep 20, 2024 at 1:21 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Thu, 19 Sep 2024 01:04:40 +0300
> Isaac Boukris <iboukris@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.