This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: clock_getres() problem


The resolution reported by clock_getres is the resolution supported by the 
timers (see create_timers). These can only be scheduled in tick intervals 
which is mostly ~ 1 ms  linux 2.6.12 and earlier. The actual precision 
reachable with clock_gettime depends on the clock sources. On IA64 this 
resolution is around 50ns and may be ~ 1 ns on a single processor system 
that can use TSC / ITC for a time source.

On Fri, 24 Jun 2005, aaron.gage wrote:

> Greetings.  I am trying to figure out a discrepancy between what is returned
> by clock_getres() and repeated calls to clock_gettime().  I was directed
> here from the glibc-bugs list, so hopefully this is the appropriate place to
> ask.
> 
> On a Fedora Core 3 machine (Intel Celeron) with glibc package
> glibc-2.3.5-0.fc3.1, I have run this code:
> 
> struct timespec ts;
> clock_getres(CLOCK_REALTIME, &ts);
> printf("Clock resolution: %d.%09d\n", ts.tv_sec, ts.tv_nsec);
> 
> The result is "Clock resolution: 0.000999848" or approximately 1
> millisecond.
> 
> However, if I do the following:
> 
>    long lastns = 0;
>    int i = 0;
>    while(i < 50) {
>       clock_gettime(CLOCK_REALTIME, &ts);
>       ns = ts.tv_nsec;
>       if(ns != lastns) {
>             printf("%d ", ns - lastns);
>             lastns = ns;
>             i++;
>       }
>    }
> 
> then I get back values ranging from 3000-5000 nanoseconds (3-5
> microseconds).
> 
>  
> 
> That is, clock_getres() is reporting 1ms resolution, but the clock is really
> able to provide 3-5us resolution.  Why doesn't clock_getres() report this?
> 
> Is there any way to get these to agree?
> 
> Thanks.
> 
> --Aaron
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]