3

I am using time stamp counter in my C++ programme by querying the register. However, one problem I encounter is that the function to acquire the time stamp would acquire from different CPU. How could I ensure that my function would always acquire the timestamp from the same CPU or is there anyway to synchronize the CPU? By the way, my programme is running on 4 cores server in Fedora 13 64 bit.

Thanks.

osgx
  • 90,338
  • 53
  • 357
  • 513
Leslieg
  • 31
  • 1
  • 3
  • You don't say what you are using the TSC for, but beware that the TSC might also return unexpected values when your cpu uses frequency scaling. – Fabian Nov 02 '10 at 08:04
  • Fabian, did you see unexpected? The expectation is described fully in intel manual, most CPUs are "constant TSC" which will not change with freq. And it is not a CPU tick counter, but counter of Bus Freq*fixed multiplier. – osgx Jul 07 '11 at 15:13

3 Answers3

5

Look at the following excerpt from Intel manual. According to section 16.12, I think the "newer processors" below refers to any processor newer than pentium 4. You can simultaneously and atomically determine the tsc value and the core ID using the rdtscp instruction if it is supported. I haven't tried it though. Good Luck.

Intel 64 and IA-32 Architectures Software Developer's Manual

Volume 3 (3A & 3B): System Programming Guide:

Chapter 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.

Intel also has a guide on code execution benchmarking that discusses cpu association with rdtsc - http://download.intel.com/embedded/software/IA/324264.pdf

ksguill
  • 3
  • 2
Safayet
  • 51
  • 1
  • 2
  • 2
    Will TSC of different cores in single physical CPU or cores from multisocket system be the same? – osgx Jul 07 '11 at 15:14
1

In my experience, it is wise to avoid TSC altogether, unless you really want to measure individual clock cycles on individual cores/CPUs.

Potential problems with TSC:

  • Frequency scaling. Counter does not increment linearly with time...
  • Different clocks on different CPUs/cores (I would not rule out different frequency scaling on different CPUs, or even differently clocked CPUs - though the latter should be rare).
  • Unsynchronized counters on different CPUs/cores (even if they use the same frequency).

This basically boils down to that you can only use the TSC to measure elapsed CPU cycles (not elapsed time) on a single CPU in a single threaded application, if you force the affinity for the thread.

The preferred alternative is to use system functions. The most portable (on Unix/Mac) is gettimeofday(), which is usually very accurate. A more appropriate function might be clock_gettime(), but check if it is supported on your system first. Under Windows you can safely use QueryPerformanceCounter().

marcus256
  • 231
  • 2
  • 6
  • 4
    On Linux gettimeofday and clock_gettime are cleverly converted into library calls (rather than being true system calls) which use rdtsc and scale/offset the result as appropriate for the exact platform you're using (some newer CPUs actually have the TSC synchronized across cores or keep it monotonic even during speedstep operations). The performance and accuracy is much higher than "classic" UNIX gettimeofday. – Ben Jackson Nov 07 '10 at 20:15
0

You can use sched_setaffinity or cpuset feature that lets you create a cpuset and assign tasks to the set.

osgx
  • 90,338
  • 53
  • 357
  • 513
Madhusudan challa
  • 1
  • 1