Re: need help while implementing a timer.
From: Floyd Davidson (floyd_at_barrow.com)
Date: 11/17/03
- Next message: Gernot Frisch: "case insensitive fopen"
- Previous message: Michel Bardiaux: "Re: Portability of executable binaries"
- In reply to: nikhil bhargav: "Re: need help while implementing a timer."
- Next in thread: nikhil bhargav: "Re: need help while implementing a timer."
- Reply: nikhil bhargav: "Re: need help while implementing a timer."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 17 Nov 2003 04:35:39 -0900
nikhilbhargav_nsit@indiatimes.com (nikhil bhargav) wrote:
>Daniele Tamino <arkaam@libero.it> wrote in message news:<bp8d22$8k9$1@lacerta.tiscalinet.it>...
>> Daniele Tamino wrote:
>> >
>> I'll just answer myself, after a little test: setitimer has a higher
>> accuracy, not 20ms, but I was using nanosleep and such which *should*
>> have a high accuracy, because the interval is specified in nanoseconds,
>> but they round it up to 20ms for some reason...
>> Bye!
>>
>> Daniele
>
>hello!,
>
>I am thankful to all of the programming experts who have read my
>problem and adviced me. I will try the solution and let you know.
>
>Further, Linux on my system doesnot have a timer granularity of 10 ms.
>I am working at preset on a i386 based host but all my applications
>will be porting to powerppc based target soon having any linux based
>RTOS. SO there timers of nano granularity is availbale but as of now i
>need a timer of 1 ms granularity for host testing.
>
>thnks,
>
>nikhil
All of these variations observed are certainly real! It all
depends...
On a i386 system running a 2.4 kernel, HZ is defined as 100,
which gives the mentioned 10ms granularity for the scheduler.
However, grepping the include files for a 2.6.0 kernel shows a
varietal plethora of values for HZ depending on the
architecture.
asm-ia64/param.h: #define HZ 1024
asm-alpha/param.h: #define HZ 1024
asm-alpha/param.h: #define HZ 1200
asm-i386/param.h: #define HZ 1000
asm-m68knommu/param.h: #define HZ 1000
asm-mips/param.h: #define HZ 1000
asm-parisc/param.h: #define HZ 1000
asm-ppc64/param.h: #define HZ 1000
Several of the above also had other defines setting HZ to 100,
so there may be variations depending on configuration.
A few tests on an i386 box with a 2.6.0-test7 kernel verified
that it is no longer restrained by a 10 ms scheduler
granularity.
The tests showed some interesting things that I'd never noticed
before. With a 2.4 kernel (on an old 400Mhz Intel PII) and on
my old laptop with a 2.2 kernel and 266Mhz PII, there is a big
difference in what happens when a process delays using usleep(),
nanosleep(), or select(). For reasons that I don't know, the
granularity with usleep() was 20ms, which seemed to be
relatively constant if there is light loading on the cpu.
Calling select() resulted in a 10ms delay Calling nanosleep()
gave results that varied wildly between 10 and 20ms on the
faster cpu, and between 15ms and 25ms on the slower one. (That
doesn't fit with what Daniele reported, which was that
nanosleep() gave the 20ms granularity, so we probably have
architectures???)
That was in a loop which gettimeofday() measured at 800-1100
microseconds, both systems, when no delay was added. The delay
was set for 100 microseconds, but different delays make no
difference as long as it is significantly less than the
scheduler granularity.
A different box running a 2.6.0-test7 kernel does the loop in
roughly 200 microseconds with no delay. (A much faster cpu is
part of the reason for the speed difference, not just the
kernel; but the similarity in times between the other two
machines suggests the kernel has more effect on it than the cpu
speed). With the 2.6 kernel there doesn't seem to be any
significant difference with the different delay functions. The
typical range was 1 to 5 ms, but some times were less than 1ms,
and since this box is always doing things the high end was often
far more than any 10-20ms. (It is also a dual cpu SMP box, and
I had the loop wired to show which cpu it was running on, and
did not notice any tendancy for either faster or slower times if
a cpu switch took place while the process was delayed.)
One thing though, the clock() function itself has 10ms
granularity, and *never* reports any finer intervals.
Nikhil, you might want to look at using a 2.6.0 kernel for
development if you don't already have that.
-- Floyd L. Davidson <http://web.newsguy.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd@barrow.com
- Next message: Gernot Frisch: "case insensitive fopen"
- Previous message: Michel Bardiaux: "Re: Portability of executable binaries"
- In reply to: nikhil bhargav: "Re: need help while implementing a timer."
- Next in thread: nikhil bhargav: "Re: need help while implementing a timer."
- Reply: nikhil bhargav: "Re: need help while implementing a timer."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
