timer resolution problem in mic

[Surya_Narayanan_N_]

My main aim was to insert 1ms delay in xeon phi coprocessor but I was getting ~9ms difference in my results. So, I tried experimenting with xeon host machine and phi coprocessor to find the timer resolution. I executed the following code:

#include <stdio.h>
#include <time.h>
#include <sys/time.h>

int main()
{
struct timespec tim, tim2;
tim.tv_sec = 0;
tim.tv_nsec = 100000;
struct timeval tv;
double temp_2=0;
int i =0;
for ( i=0;i<1000;i++)
{
gettimeofday(&tv, NULL);
double t1=tv.tv_sec+(tv.tv_usec/1000000.0);

nanosleep(&tim , NULL);

gettimeofday(&tv, NULL);
double t2=tv.tv_sec+(tv.tv_usec/1000000.0);

temp_2+=(t2-t1);
}
printf("Nano sleep successfull %lf\n",temp_2/1000);

return 0;
}

Running the following program in host:

./a.out Nano sleep successfull 0.000155

Running in xeon phi coprocessor:

./nsleep_mic Nano sleep successfull 0.009998

soo I get almost 90% errored wait in xeon phi.

1. why does such erroneous wait happens?
2. How to solve it if I want a sleep time of 1ms?

[Sumedh_N_Intel]

Hi, 

I noticed that there is a bug in your code. You are inserting a delay of 0.1ms instead of 1ms.

Also, in my opinion, the resolution of gettimeofday is not good enough to measure 1ms delays. Could you try using TSC instead? 

[TaylorIoTKidd]

Though gettimeofday() has fields for microseconds, I've found that its resolution is around 10ms.

Have you tried using __rdtsc()? Or the timing code in TBB? 

Regards
--
Taylor
 

[McCalpinJohn]

We discovered that our Xeon Phi SE10P coprocessors were able to use two different mechanisms to implement the gettimeofday() clock -- the TSC and the external 10 millisecond timer ("jiffies").    When using the TSC, the resolution of gettimeofday was 1 microsecond, while using "jiffies" resulted in gettimeofday resolution of 10 milliseconds.

According to an Intel white paper entitled "System Administration for the Intel Xeon Phi Coprocessor" (no document number, but the PDF appears to have been created on 2013-03-01), you can find which timer is in current use running this command on the coprocessor:

        cat  /sys/devices/system/clocksource/clocksource0/current_clocksource

You can actually override the current choice with a command like:

     echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource

But note that if the OS thinks that the TSC is not reliable it may switch back to using jiffies at any time.

[Sumedh_N_Intel]

It would also be advisable to turn off power management. 

In general system calls like sleep() and nanosleep() will wake up the process only after the specified time has elapsed or a signal is delivered to the process. This doesn't mean they will be woken up exactly at the end of the time period. The only guarantee Linux provides is that they will sleep for as long as you specify i.e. the process will not be woken up any sooner. Generally, there are always scheduling delays and other wake up related latencies.