Re: Accuracy of rte_get_tsc_hz() compared to linux

[Isaac Boukris <iboukris@gmail.com>]

On Fri, Sep 20, 2024 at 5:39 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Fri, 20 Sep 2024 06:19:35 +0300
> Isaac Boukris <iboukris@gmail.com> wrote:
>
> > 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.
>
> 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".

On linux we could just read /proc/cpuinfo and see what the kernel thinks.

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

In practically all my tests, on machines without tsc_known_freq, the
value determined by our linux estimation code with rounding lowered to
1KHz, was much better (closer to kernel value, actually exact the
kernel value except one case where they differed in a couple of KHz).
What would repeated tests give us? I don't think the kernel value
changes, does it?

In fact I think we should lower the rounding in our linux estimation
code to 1KHz (and its time from 100ms to 200ms, just to be on the safe
side, the kernel does a full second), as well as lower the rounding of
our common code to 1MHz. This will simply be more accurate.