Hello,
Thanks.
I did tried nanosleep and it gave really more than 1 micorsecond.
also:
from "man nanosleep":
.....
.....
BUGS
The current implementation of nanosleep is based on the normal kernel
timer mechanism, which has a resolution of 1/HZ s (i.e, 10 ms on
Linux/i386 and 1 ms on Linux/Alpha).
.......
.......
I assume that from the same reasons, also setitimer() will not do the job.
As I understand from you I am not permitted to use "outb" from
userspace, and this trick with 0x80 is not good for user space.
(In my case it does not stall the machine, but not much runs on it).
So is there a way to achieve 1 microsec delay from user space ?
Regads,
John
On 8/18/05, Erik Mouw <J.A.K.Mouw@xxxxxxxxxxxxxx> wrote:
> On Thu, Aug 18, 2005 at 09:22:55AM -0400, John Que wrote:
> > I want to use delays of 1 microsend on linux 2.4 or linux 2.6 kernel
> > on x386 platform.
> >
> > As we know, usleep depends on the HZ of the system.
>
> It is?
>
> > So both in 2.4 and in 2.6 we cannot achieve 1 microsec delay calling
> > udelay (the man page of usleep says itslef that
> > "Probably not accurate on many machines down to the microsecond.").
>
> You certainly can. RTFM, usleep(2) says in the NOTES section:
>
> This function is obsolete. Use nanosleep(2) or setitimer(2) instead.
>
> > According to "Linux I/O port programming mini-HOWTO"
> > (http://www.tldp.org/HOWTO/IO-P ort-Programming-2.html)
> > you can use outb on 0x80 to create a dealy.
>
> The outb() trick can't be used in userland, you're stalling the
> complete machine by doing so!
>
> > So I added this snippest of code
> > and trird to use outb('a',0x80) for creating a sleep time in
> > resolution of microseconds thus:
> > ............
> >
> > ioperm(0x80, 1, 1);
> >
> > for (i=0;i<10000;i++)
> > outb('a',0x80);
> > ............
> >
> > On 3 machines (each of them had a different strength, one of the with
> > 2.6
> > kernel and the other two with 2.6 kernek) it gave a result of
> > about 1.4 microsec for every such call, while on a differnet macine it
> > gave a much
> > higher average of 2.16 microsec.
>
> That doesn't surprise me, the kernel is allowed to reschedule your
> process during the for() loop, so depending on the system load, the
> actual delay varies a lot.
>
>
> Erik
>
> --
> Erik Mouw
> J.A.K.Mouw@xxxxxxxxxxxxxx mouw@xxxxxxxxxxxx
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFDBJh6/PlVHJtIto0RAiYfAJ9NuG1M8qwu4U34I2Iv12eS7eur5gCggojz
> /R9JT5rqug1QhV1ZFBI0Yds=
> =y6Xk
> -----END PGP SIGNATURE-----
>
>
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
