Accuracy of rte_get_tsc_hz() compared to linux

[Stephen Hemminger]

On Fri, 20 Sep 2024 06:19:35 +0300
Isaac Boukris <iboukris at gmail.com> wrote:

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

The known freq flag doesn't appear to be a CPU flags property, but more
of a property that kernel sets when it decides "this is good enough".

Really getting better value would require some sort of repeated check
(maybe an alarm callback), and using cpu value as a starting point.