From AMD CPUID Specification doc:
Bit 8 : TscInvariant: 1 = TSC invariant. The TSC rate is ensured to be invariant across all P-States, C-States, and stop grant  transitions (such as STPCLK Throttling); therefore the TSC is suitable for use as a source of time. 0 = No such guarantee is made and software should avoid attempting to use the TSC as a source of time.

From Intel B-Spec 3A/SDM:
16.12.1 Invariant TSC The time stamp counter in newer processors may support an enhancement, referred to as invariant TSC. Processor's support for invariant TSC is indicated by CPUID.80000007H:EDX[8]. The invariant TSC will run at a constant rate in all ACPI P-, C-. and T-states. This is the architectural behavior moving forward. On processors with invariant TSC support, the OS may use the TSC for wall clock timer services (instead of ACPI or HPET timers). TSC reads are much more efficient and do not incur the overhead associated with a ring transition or access to a platform resource.

From Intel Software blog(low):
On Nehalem, the TSC runs at a constant frequency of MSR_PLATFORM_INFO[15:8] * 133.33MHz.  MSR_PLATFORM_INFO[15:8] will report the lower of the ratio at which the part was stamped or a separate MSR to lower the ratio to provide TSC consistency across multi-socket systems with parts of different frequencies.

It _seems_ dhcp38's X5650 CPU(Nehalem) supports TSC Invariant, ie. TSC counter is running of a separate clock(always at same frequency),independent of proc state and DVFS.  Hence RDTSC should return cycles independent of CPU Frequency.

When running 'sleep' microbenchmark on host, cpu frequency is:
bash$ cat /proc/cpuinfo | grep MHz
cpu MHz        : 1596.000

When running 'emptyloop' microbenchmark on host, cpu frequency on one core becomes:
bash$ cat /proc/cpuinfo | grep MHz
cpu MHz        : 2661.000

And in both cases, clock_gettime, gettimeofday, rdtsc/2661  were very close.
Note: Haven't verified with guest image yet.
Note: VMware supports "monitor_control.virtual_rdtsc=true/false" in vmx file. it _may_ mess up with rdtsc(not verified).


Dushyant installed '/usr/bin/cpuid' program on dhcp38 to confirm if bit 8 is set or not. but unfortunately we couldn't complete the checking due to some issue in /usr/bin/cpuid program.


-- 
Regards,
Deepak Ravi