Query on ClockCycles()

Hi all,
I need to calculate the time taken for doing some action(precision in nano seconds). I used ClockCycles() to calculate the time taken. ClockCycles() returns the current value of a free-running 64-bit cycle counter. The application is expected to run continuously for 6 months. So is there any issue in using ClockCycles() API to get time. Will the cycle count reset during this period.

Regards,
hello

Of course ClockCycles will overflow - probably in the order of a minute or two! Note also that on multicore x86, each core has its own counter - so you want to attach your program to one particular core.

Assume a 2Gig clock the first 31 bit will wrap around every seconds so that leaves 33 bits for representing seconds, hence thats 8589934592 seconds, or 143165576 minutes or 2386092 hours, or 99240 days or 14202 weeks or 273.133 years. Havent double check the math ;-)

Oops. I was thinking of 32-bits. With 64 I guess you need not worry about overflow!

Ok , thank you very much

And don’t forget what Dennis said about attaching to a core. ;-).

So before taking the clock cycle, i need to lock the thread to run in a single core and unlock it afterwards. I need time in nano seconds precision. Should i go for any other API?

That’s basically correct. Whether you unlock it afterwards is up to you. The catch in this is whether you are in a hurry. Locking a thread could be time consuming, especially if you do it each time you want to measure a time interval. You could lock the thread at startup and leave it. This might create other issues in your system.

If you have a completely spare cpu, you could lock everything else off of it, and have a single thread on that cpu that calls ClockCycles() in a loop, saving the result to shared memory. Then your threads could read the clock by reading the shared memory. This sounds a little crazy to me, but it could work. In case you consider this, beware of a hyper-threaded cpu.

Ok, I need to get the time frequently so that it will a overhead to lock a thread. Is there any other API to get time in precision of nano seconds

If you need to get the time frequently without the overhead of locking a thread to a cpu, you will have to lock it once and leave it locked. This obviously has some disadvantages, but there is no other API to help you out.

You could attach a piece of hardware with a high speed counter, but I can’t think of any other way.

If you need to get the time frequently without the overhead of locking a thread to a cpu, you will have to lock it once and leave it locked. This obviously has some disadvantages, but there is no other API to help you out.

You could attach a piece of hardware with a high speed counter, but I can’t think of any other way.

Hi all,

      If ClockCycles() is used on an SMP machine, we must  “lock” the thread to a single CPU. 

In case of quad core multicore processor, will the locking mechanism work properly ?
We see some variations during testing on quad core. Please help

Regards,
hello

I don’t think this is the case. ClockCycles() should function without locking to a processor. On the other hand, the accuracy of ClockCycles() may not be all that good. At best it would be + or - the timer interrupt frequency.

One thing to be aware of is that you must turn off ‘hyper threading’ in the BIOS.

Hyperthreading is NOT a real CPU like a 2nd core is. But to QNX it will appear as a full CPU and threads will be scheduled on it as if they are. The execution time of a thread on a Hyperthread CPU is much slower than on a primary/secondary core.

Tim

On modern x86 process ( don’t know exactly what model it started), the rdtsc will be the same on every core of a processor, even if a core change frequency to save power.

The RDTSC has a mode to switch it to measure time and not clock cycles ( which is the original intent ). I don’t know if QNX switches the mode.