Clock_realtime_hr

selalerer · 07-21-2009, 03:13 AM

Hi all.

Machine details:
~~~~~~~~~~~~~~~~
We have at work a Linux server. I think it is a RedHat Enterprise 4. This path:

/usr/include/c++/4.1.2/x86_64-redhat-linux/

exists, so it will probably help identifying the version. This is the uname -a output:

Linux XXXX 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

If it makes any difference, this is virtual server on Xen.

The problem:
~~~~~~~~~~~~
I want to use sys_clock_gettime(CLOCK_REALTIME_HR) but the compiler complains that CLOCK_REALTIME_HR is not defined.

Anybody has some experience with that? Knows what I'm doing wrong?

More details:
~~~~~~~~~~~~~
This is from 'man 2 clock_gettime':

clock_gettime returns the current timespec value of tp for the specific clock, which_clock. The values that clockid_t currently supports for POSIX.1b timers, as defined in include/linux/time.h, are:

CLOCK_REALTIME_HR
High resolution version of CLOCK_REALTIME.

But I can't find this CLOCK_REALTIME_HR in /usr/include/linux/time.h.
I tried including <linux/time.h>, it doesn't make it any better.

Thank you for any assistance,
Sela.

paulsm4 · 07-22-2009, 01:47 PM

Try "gettimeofday()". For example:

Code:

struct timeval tv;
struct timezone tz;
struct tm *tm;
gettimeofday(&tv, &tz);
tm=localtime(&tv.tv_sec);
printf(" %d:%02d:%02d %d \n", tm->tm_hour, tm->tm_min,
    tm->tm_sec, tv.tv_usec);

selalerer · 07-23-2009, 03:42 AM

Quote:

Originally Posted by paulsm4

Try "gettimeofday()". For example:

Code:

struct timeval tv;
struct timezone tz;
struct tm *tm;
gettimeofday(&tv, &tz);
tm=localtime(&tv.tv_sec);
printf(" %d:%02d:%02d %d \n", tm->tm_hour, tm->tm_min,
    tm->tm_sec, tv.tv_usec);

Thanks, but we rather have a higher resolution timer. The CLOCK_REALTIME_HR seems like the right solution, we are just having trouble compiling it. Any help would be appreciated. A better solution, if someone has such a solution to suggest, is also welcomed.

sd9 · 07-23-2009, 04:55 AM

CLOCK_REALTIME_HR is removed. Use CLOCK_REALTIME_HR = CLOCK_REALTIME.

Referenced from : http://www.nabble.com/Re:-RT,-timers...-p6291002.html

selalerer · 07-23-2009, 08:24 AM

Quote:

Originally Posted by sd9

CLOCK_REALTIME_HR is removed. Use CLOCK_REALTIME_HR = CLOCK_REALTIME.

Referenced from : http://www.nabble.com/Re:-RT,-timers...-p6291002.html

Unfortunately the resolution of this clock is too low for us. On other Unix machines we use gethrtime(), but this function is not available in Linux. Is there some other replacement or do we have to resort to Assembly?

orgcandman · 07-23-2009, 09:29 AM

Quote:

Originally Posted by selalerer

Unfortunately the resolution of this clock is too low for us. On other Unix machines we use gethrtime(), but this function is not available in Linux. Is there some other replacement or do we have to resort to Assembly?

CLOCK_REALTIME is the same as CLOCK_REALTIME_HR, so I'm not sure why you're saying that it is insufficient. If CLOCK_REALTIME is insufficient, CLOCK_REALTIME_HR would also be insufficient.

Additionally, see this for more information on what options you'll need to enable:
http://kerneltrap.org/node/6750

-Aaron

selalerer · 08-08-2009, 12:21 PM

Quote:

Originally Posted by orgcandman

CLOCK_REALTIME is the same as CLOCK_REALTIME_HR, so I'm not sure why you're saying that it is insufficient. If CLOCK_REALTIME is insufficient, CLOCK_REALTIME_HR would also be insufficient.

Additionally, see this for more information on what options you'll need to enable:
http://kerneltrap.org/node/6750

-Aaron

Hmm.. That's disappointing. I did not think Linux will have any disadvantage on other Unix machines we use (HP-UX, AIX).

Maybe we can set it as a requirement of our product to install these high resolution timers patches. I'll have to consult my bosses on that :-). One thing is for sure, we can not do with the 1 millisecond resolution the system calls offer now.

Thanks for the info,
Sela.

dwhitney67 · 08-08-2009, 04:42 PM

The CLOCK_REALTIME is correct. Use it with clock_gettime().

Example usage:

Code:

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

int main()
{
   struct timespec tv;
   clock_gettime(CLOCK_REALTIME, &tv);

   printf("seconds:     %u\n", (unsigned int) tv.tv_sec);
   printf("nanoseconds: %u\n", (unsigned int) tv.tv_nsec);

   return 0;
}

When linking the code, indicate that you want to use the real-time library; in other words, specify -lrt.

Code:

gcc gettime.c -lrt -o gettime

selalerer · 08-09-2009, 10:49 AM

Quote:

Originally Posted by dwhitney67

The CLOCK_REALTIME is correct. Use it with clock_gettime().

Example usage:

Code:

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

int main()
{
   struct timespec tv;
   clock_gettime(CLOCK_REALTIME, &tv);

   printf("seconds:     %u\n", (unsigned int) tv.tv_sec);
   printf("nanoseconds: %u\n", (unsigned int) tv.tv_nsec);

   return 0;
}

When linking the code, indicate that you want to use the real-time library; in other words, specify -lrt.

Code:

gcc gettime.c -lrt -o gettime

Already did that, the resolution is a bit below one millisecond. That's not a high enough resolution for us.

Thank you.

paulsm4 · 08-09-2009, 01:02 PM

Just because you get a *value* in nanoseconds, it doesn't mean that it's *accurate* to nanoseconds!

It isn't.

This is equally true of Linux, HP-UX, AIX, Solaris ... and most definitely true of Windows.

IMHO .. PSM

gangettan · 08-09-2009, 04:00 PM

Wow ... This is a really heated discussion ...

linux

haikan · 08-09-2009, 04:07 PM

Quote:

Originally Posted by selalerer

Hmm.. That's disappointing. I did not think Linux will have any disadvantage on other Unix machines we use (HP-UX, AIX).

Maybe we can set it as a requirement of our product to install these high resolution timers patches. I'll have to consult my bosses on that :-). One thing is for sure, we can not do with the 1 millisecond resolution the system calls offer now.

Thanks for the info,
Sela.

Did you read the manpage for the clock_* functions? It would answer most of your questions. clock_getres gives you the clock resolution on your system, if your kernel is tickless it will return one nanosecond.

This code prints "Clock res = 0s:1ns" on my system:

Code:

#include <stdio.h>
#include <time.h>
#include <assert.h>

int main() {
  struct timespec res;
  assert( clock_getres(CLOCK_REALTIME, &res) != -1);
  printf("Clock res = %ds:%ldns\n", res.tv_sec, res.tv_nsec);
  return 0;
}

Ah, sorry. Now that I've re-read you post I see that you are using an ancient kernel. The merging of bits from Ingo Molnar's realtime patch into the vanilla kernel started around 2.6.18 AFAIK, so I think it can be tickless. Also check out kernel preemption.

dwhitney67 · 08-09-2009, 04:16 PM

Quote:

Originally Posted by selalerer

Already did that, the resolution is a bit below one millisecond. That's not a high enough resolution for us.

Thank you.

I suspect that you do not even know what a millisecond is. FYI, it is 1/1000 of a second. A microsecond is 1/1000000 of a second. A nanosecond is 1/1000000000 of a second.

If your POS system can't even do millisecond resolution, then you and your client need serious help.

haikan · 08-09-2009, 05:55 PM

Quote:

Originally Posted by dwhitney67

I suspect that you do not even know what a millisecond is. FYI, it is 1/1000 of a second. A microsecond is 1/1000000 of a second. A nanosecond is 1/1000000000 of a second.

If your POS system can't even do millisecond resolution, then you and your client need serious help.

I think you're being unfair. His kernel version is 2.6.18, and back then system calls that set timeouts was limited by the resolution of the software clock, which measures time in jiffies. In 2.6.18 jiffies could be 0.01, 0.004, or 0.001 seconds, depending on the kernel configuration. High resolution timers wasn't introduced until 2.6.21.

My advice to the OP would be to upgrade the kernel to at least version 2.6.21, or if you can't then apply the realtime patches for your kernel version.

paulsm4 · 08-09-2009, 06:25 PM

My point is this:

1. If you think you *need* microsecond (or nanosecond) granularity, you possibly have a design problem (for example, relying on polling instead of blocking). I would suggest revisiting the original requirements, and considering other design alternatives.

2. If you think you're actually going to *get* nanosecond resolution, you're probably mistaken (even with decent hardware, up-to-date kernels, and realtime extensions)(and *certainly* with most other, non-Linux multitasking, preemptable operating systems; including most/all flavors of Unix and Windows).

IMHO .. PSM