<div dir="ltr">Using rdtsc to timestamp RTT of packets<br><br>Stephen/Gabor/Harry: Gents thanks for the guidance; this mailing list is great. The message is rdtsc is just fine. Got it.<br><br>The command line (from Harry):<br>>lscpu | egrep "constant_tsc|nonstop_tsc"<br>is operationally ideal: specific, easy, and answers the issue of invariance/constancy clearly.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 6, 2023 at 11:56 AM Stephen Hemminger <<a href="mailto:stephen@networkplumber.org">stephen@networkplumber.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 5 Mar 2023 20:01:15 -0500<br>
fwefew 4t4tg <<a href="mailto:7532yahoo@gmail.com" target="_blank">7532yahoo@gmail.com</a>> wrote:<br>
<br>
> I think rdtsc does all this. But then I read [1]:<br>
> <br>
>    - The TSC is not always invariant<br>
>    - And of course context switches (if a thread is not pinned to a core)<br>
>    will invalidate any time difference<br>
>    - The TSC is not incremented when the processor enters a deep sleep. I<br>
>    don't care about this because I'll turn off the power saving modes anyway<br>
<br>
Stack Overflow is only one step better than ChatGPT in giving<br>
partially correct answers.<br>
<br>
TSC is almost always works well on modern processors.<br>
The Linux kernel aligns all the TSC values for each core at boot up.<br>
It is invariant (derived from a single clock source) unless you have some<br>
poorly designed NUMA system.  In the past, there were some CPU's that<br>
did bad things during suspend, but that is fixed in current generations.<br>
<br>
Bottom line: that advice is no longer true.<br>
</blockquote></div>