Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
65 Views

RDTSC only returns evenly numbered values on some chips

I've found that the RDTSC instruction only ever returns even values on several of the chips I have access to.  These include:

Intel(R) Xeon(R) CPU E5620  @ 2.40GHz

2.4 GHz 8-Core Intel Core i9

Intel(R) Xeon(R) CPU E3-1275 v6 @ 3.80GHz

Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz

However, there are some chips that return both even and odd values:

Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz

Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz

I'm running on various versions of the linux kernel including 4.4.12, 4.4.111, 5.4.72.

This occurs both when calling rdtsc() from inside the kernel as well as the attached user-space program.  No matter when/where I call RDTSC and no matter how many times I do so and no matter what I put in-between those calls -- they are always even values.

This behavior seems broken.  Did something go wrong with all the various tweaks to TSC behavior that have occurred over the years?  Or is this just an expected side-effect of various CPU instruction processing optimizations?

0 Kudos
5 Replies
Highlighted
Community Manager
44 Views

Hello rerickson,


Thank you for posting your question on this Intel® Community.


To better assist you, I would like to gather additional information about this behavior. 


  • What is the Linux distribution(s) you are using?
  • Are you currently developing software?
  • How is this behavior impacting your project/environment?


Regards,


Wanner G.

Intel Server Specialist


0 Kudos
Highlighted
Beginner
34 Views

Our linux distribution is “home-grown” (so difficult to quantify) but based on Debian.

 
But behavior is the same on macOS Catalina and MacOS Big Sur.
 
Versions of glibc on linux:
- 2.19
- 2.28
 
 
Versions of gcc:
- 4.9.2
- 8.3.0
- 8.4.0
 
Tried different optimization levels (-O0 -O1, O2, and O3), but no change in behavior.
 
Yes, I am developing SW.  This impacts our project as we are using “timestamp" deltas (based on output obtained from RDTSC) for entropy generation.  The least significant bits of these deltas are expected to contain the most entropy.  But in this case bit 0 is never set and so has no entropy.
 
While there are workarounds (e.g. use CLOCK_MONOTONIC), there are lingering concerns about RDTSC not working as expected (and thus being able to rely on it at all for timestamps in any part of our code).  The idea of a CPU instruction apparently not working “as advertised” has created much concern — regardless of whether we end up using RDTSC or not. 
  
The fact that changing compiler optimization levels have no impact suggests that the compiler isn’t involved (or am I not understanding that correctly?).
 
If this information isn’t sufficient, perhaps you could pose the question differently or perhaps ask me to try something different in order to better test some theory/hypothesis?
 
Thanks

 

0 Kudos
Highlighted
Community Manager
25 Views

Hello rerickson,


Thank you for providing additional details about your project.


For Software Development inquiries, our recommendation is that you submit your questions to the Intel® Developer Zone.


Intel® Developer Zone - Contact Page

https://software.intel.com/en-us/support


You can submit your ticket through the Online Service Center at https://www.intel.com/supporttickets for support.


See How to Create a Support Request at the Online Service Center.

https://software.intel.com/en-us/articles/how-to-create-a-support-request-at-online-service-center


Regards,


Wanner G.

Intel Server Specialist


0 Kudos
Highlighted
Beginner
16 Views

I just want to make sure I'm understanding this.  CPU instructions themselves are considered software and *not* hardware related?

For example, if I were to call the CPUID instruction and the bits it returned didn't match the physical specs for that chip then it would be a software problem?

I understand that for a company like Intel that does such a wide range of hardware and software that the distinction between the two is different than what I might expect.

Are you assuming that this *must* be a problem with the assembler?  How come the exact same output works on some Intel chips but now others?  Given that we're talking about a CPU instruction (and not something "fancy") how is that not a HW issue?

Please help me to understand how you're making the HW vs SW distinction in this case.

Thanks

 

0 Kudos
Highlighted
Community Manager
8 Views

Hello rerickson,


Thank you for your response.


"CPU instructions themselves are considered software and *not* hardware related?"

I would like to clarify that this is not what I meant.


Depending on the inquiry you have, and since you are currently working on a software development project, a different support channel would be recommended.


In this scenario, our recommendation is that you submit your question to the Intel® Developer Zone to obtain additional support for this inquiry.


Wanner G.

Intel Server Specialist


0 Kudos