0

I am currently working on shared memory I want to calculate the time taken for the thread1 to write and thread2 to read from shared memory. For this I used:

 clock_gettime(CLOCK_REALTIME,&start)

in thread1, and after reading from thread2. I again called:

 clock_gettime(CLOCK_REALTIME,&end)

The time taken for reading and writing can be calculated from:

 dt = (double) (end.tv_sec - start.tv_sec) +
((double) (end.tv_nsec - start.tv_nsec) / 1000000000.0);

But every time I run the program I am getting different results. What am I doing wrong?

dbush
  • 205,898
  • 23
  • 218
  • 273
anikhan
  • 1,147
  • 3
  • 18
  • 44
  • 1
    When you say "different results", can you please be more specific? What ranges do you get? And since you use the wall clock, you are aware of that Linux is a multi-tasking operating kernel, that might pause your process and let other processes work, and you have no real control over how long or how many times your process might be paused, and that of course will skew your results. To get a better result, do the operation thousands (or even millions) of times, and calculate the average time. – Some programmer dude Sep 08 '15 at 12:08
  • Thanks Joachim, We are using priority based pre-emptive scheduling. Other than interrupts assume, the highest pri thread will scheduled. Sometimes we are getting 0.000367 sec and sometimes 0.004442 sec, i assume this margin is high. Correct me if i am wrong – anikhan Sep 08 '15 at 12:13
  • Are there other processes of equal or higher priority running in the system? If not then yes that seems like a pretty big range. – Some programmer dude Sep 08 '15 at 12:23
  • 1
    The overhead in `clock_gettime()` - which has to issue a serialising instruction - is likely an order of magnitude greater than the time for a single write/read to shared memory. Try ping-ponging the data between the two processes thousands of times, and measure *that* (then divide by the number of times). – caf Sep 08 '15 at 13:57
  • Also, for applications like this, you should probably use `CLOCK_MONOTONIC` instead of `CLOCK_REALTIME` - see http://stackoverflow.com/questions/3523442/difference-between-clock-realtime-and-clock-monotonic and http://linux.die.net/man/ – sonicwave Sep 09 '15 at 10:51

1 Answers1

2

I've used this method of measuring before and you are doing nothing wrong. Even when you have your scheduling right your output will always fluctuate.

The overhead I used to have was around 250 microseconds if the thread didn't get interrupted by another process, but I suppose this is very dependent on the CPU power as well.

For the overhead: Try measuring a few hundreds/thousands times with an empty body, check the lowest (least interrupted) output to examine the overhead.

For your results: Try the same and take again the lowest value, this way you can approach the actual value you are looking for. Keep in mind that a single read and write might be not-measurable fast.

koldewb
  • 452
  • 1
  • 5
  • 18