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 unsub
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 accurat
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
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
rtain as to how accurate timings below 14 msec can be on this
> > > hardware using the kernel's internal timer.
> >
> >timers can be set MUCH faster than that.
>
> In principle, yes. usleep() timers can be *set* to 1 usec. That's not the
> question. The que
Sorry everyone, I had initially posed my for loop wrong... I meant to say for(i = 0; i
< 1000; i++).
Mark Hahn clarified the issue and usleep is not actually accurate (provably) and the
man page actually has a disclaimer. To me, it seems like usleep(2000) * 50
itterations actually give
> 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
I'm not sure what you are saying, but yes there are 1 million microseconds in a
second 100 micro seconds that is. So my loop seems correct. Also, I am
running this on a 2 GhZ processor, so I doubt the 1000 calls to usleep can add that
much overhead. I think something is wrong
ations I encountered when
programming in VB on Windows 2000), and I think I got the actual numbers wrong.
> me uncertain as to how accurate timings below 14 msec can be on this
> hardware using the kernel's internal timer.
timers can be set MUCH faster than that.
In principle, yes. usleep()
> 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
> 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&
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?
uslee
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
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?
Thanks
Lee
#include
int main()
{
while (1)
{
int i
19 matches
Mail list logo
