Processors (Intel® Core™, Intel® Xeon®, etc); processor utilities and programs (Intel® Processor Identification Utility, Intel® Extreme Tuning Utility, Intel® Easy Streaming Wizard, etc.)
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
11688 Discussions

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
Community Manager

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?


Wanner G.

Intel Server Specialist


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?


Community Manager

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

You can submit your ticket through the Online Service Center at for support.

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


Wanner G.

Intel Server Specialist


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.



Community Manager

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