Ray Olszewski wrote:
> At 05:55 PM 6/11/2003 -0500, Lee Chin wrote:
> In fact, compiled on my system, the loop as written does introduce just
> about a 1 second delay (30 iterations take 29 seconds, timed crudely
> with a wristwatch ... just right, since the initial printf() happens
> before the f
> On my box, (a P3/450) usleep seems to have an overhead of about 1usec
> and a minimum response time of about 2
which is perfectly correct/expected.
although "overhead" isn't quite right: instead, say
it has a resolution of 1/HZ and a minimum of 2/HZ.
-
To unsubscribe from this list: s
On my box, (a P3/450) usleep seems to have an overhead of about 1usec
and a minimum response time of about 2
/* my test prog:
* (based on yours)
*/
#include
#include
struct timeval tv1,tv2;
#define PAUSE 10
int main()
{
while (1)
{
int i;
double sum=0.0,t;
e: Wed, 11 Jun 2003 21:02:17 -0400 (EDT)
To: Lee Chin <[EMAIL PROTECTED]>
Subject: Re: usleep
> > Any way... what is setrealtime? I dont have it on my linux machine
>
> it's a simple tool I wrote a long time ago, code below.
> * N O T E ***
> it can effect
> I would think the following code would wait for 1 second each
> itteration before printing hello, but it waits way too long.
> Replacing the for loop body with a usleep(100) works
> great... what am I missing here?
Essentially, that usleep() isn't actually terribly accurate for short
waits.
At 05:14 AM 6/12/2003 +0100, Riley Williams wrote:
Hi Ray.
> Now 500 x 10 = 5000 usec, or 1/200 seconds. But the loop
> actually takes 10 seconds to iterate. This implies that
> usleep() has a minimum delay of 10/500 seconds, or 20
> msec, built into it (at least on my test system).
The standa
Hi Ray.
> Now 500 x 10 = 5000 usec, or 1/200 seconds. But the loop
> actually takes 10 seconds to iterate. This implies that
> usleep() has a minimum delay of 10/500 seconds, or 20
> msec, built into it (at least on my test system).
The standard PC BIOS sets up the hardware timer with a tick
QNX. do some research on that OS. Long time ago I heard that it was a
real time OS and that programming and running programs on it was VERY
much more accurate than the standard INTEL. I don't really know what you
want... if you wan precission then this might be your solution... if you
dont... then
ED]>
Subject: Re: usleep
> On Wed, Jun 11, 2003 at 05:55:02PM -0500, Lee Chin wrote:
> > I would think the following code would wait for 1 second each itteration
> > before printing hello, but it waits way too long. Replacing the for
> > loop body with a usleep(100) w
> Any way... what is setrealtime? I dont have it on my linux machine
it's a simple tool I wrote a long time ago, code below.
* N O T E ***
it can effectively freeze your machine, since it gives you a process
which will not be prempted! it *is* useful, though, if you know
what you're doin
19:45:17 -0400 (EDT)
To: Lee Chin <[EMAIL PROTECTED]>
Subject: Re: usleep
> > I would think the following code would wait for 1 second each itteration
> > before printing hello,
>
> well, usleep takes microseconds, so as you've written it,
> you should expect it to ta
with the library or the kernel.
- Original Message -
From: Alan Bort <[EMAIL PROTECTED]>
Date: 11 Jun 2003 19:08:34 +0300
To: Lee Chin <[EMAIL PROTECTED]>
Subject: Re: usleep
> for the #include statemen I assume you are using some sort of C
> languagbe (even C, C++ or C#) W
At 08:17 PM 6/11/2003 -0400, Mark Hahn wrote:
> An i386 has a hardware timer that beats about 72 times per second, leaving
well, it has several hardware counter/timers, but that setting
is not special (and isn't it only used by DOS?)
Actually, I wrote that from memory (of timer limitations I encou
> An i386 has a hardware timer that beats about 72 times per second, leaving
well, it has several hardware counter/timers, but that setting
is not special (and isn't it only used by DOS?)
> me uncertain as to how accurate timings below 14 msec can be on this
> hardware using the kernel's inter
At 05:55 PM 6/11/2003 -0500, Lee Chin wrote:
I would think the following code would wait for 1 second each itteration
before printing hello, but it waits way too long. Replacing the for loop
body with a
usleep(100) works great... what am I missing here?
Why would you expect this loop to wait
> I would think the following code would wait for 1 second each itteration
> before printing hello,
well, usleep takes microseconds, so as you've written it,
you should expect it to take 1ms per usleep or 50ms between hello's.
further, the man page doesn't claim that it'll actually sleep
for exact
On Wed, Jun 11, 2003 at 05:55:02PM -0500, Lee Chin wrote:
> I would think the following code would wait for 1 second each itteration
> before printing hello, but it waits way too long. Replacing the for
> loop body with a usleep(100) works great... what am I missing here?
usleep = micro sleep
for the #include statemen I assume you are using some sort of C
languagbe (even C, C++ or C#) Well... my man of usleep says that it
makes the system wait for any number of microseconds... make the maths.
Anyway... I really don't remebmer the value of a microsecond... I THINK
it was something like
18 matches
Mail list logo
