Re: It's about time: a delay of 1 microsec in a user space

2005-08-23 Thread Ami Chayun
Since I see people are suggesting more and more hallucinatory solutions without providing any documentation, so I'll add my own :-) Use the sound card as a scheduler. If it works for audio, it can work for you! And for a more serious answer, look in: http://www.gardena.net/benno/linux/audio/ A

Re: It's about time: a delay of 1 microsec in a user space

2005-08-21 Thread Gilad Ben-Yossef
Rafi Gordon wrote: Hello, Thanks. You said If you really meant 1 microsecond (as opposed to 1 millisecond) Yes ,I mean it. In short: it's for a video-audio app; this app can be termed soft (or semi) real time; The terminology is not important at all. The fact is that there are scenarios w

Re: It's about time: a delay of 1 microsec in a user space

2005-08-20 Thread guy keren
On Sat, 20 Aug 2005, Rafi Gordon wrote: > may I ask ehat is the recommnded way to write a a busy wait loop? > If I am not wrong there is no "noop" command in "C" ; is there a noop > is asm to achieve this ? or simply a loop which just do dummy > operation > like incrementing some integer ? i sug

Re: It's about time: a delay of 1 microsec in a user space

2005-08-20 Thread guy keren
On Fri, 19 Aug 2005, Amos Shapira wrote: > On 8/19/05, guy keren <[EMAIL PROTECTED]> wrote: > > > perhaps your machine is slower for this because it has SMP, and hence > > requires locking (i tested on single processor machines). > > Maybe, I dunno. > I've just test on my home machine (a single C

Re: It's about time: a delay of 1 microsec in a user space

2005-08-19 Thread Rafi Gordon
Hello, Thanks. You said > If you really meant 1 microsecond (as opposed to 1 millisecond) Yes ,I mean it. In short: it's for a video-audio app; this app can be termed soft (or semi) real time; The terminology is not important at all. The fact is that there are scenarios when the timing is crit

Re: It's about time: a delay of 1 microsec in a user space

2005-08-19 Thread Amos Shapira
On 8/19/05, guy keren <[EMAIL PROTECTED]> wrote: > > On Fri, 19 Aug 2005, Amos Shapira wrote: > > > > the fact is, that i kept getting very close values - closer then the > > > > That's the statement I was looking for (and didn't see) in your first > > message - if they are identical then it coul

Re: It's about time: a delay of 1 microsec in a user space

2005-08-19 Thread guy keren
On Fri, 19 Aug 2005, Amos Shapira wrote: > > the fact is, that i kept getting very close values - closer then the > > That's the statement I was looking for (and didn't see) in your first > message - if they are identical then it could be that the call was simply > faster than system's the clock

Re: It's about time: a delay of 1 microsec in a user space

2005-08-18 Thread Amos Shapira
On 8/19/05, guy keren <[EMAIL PROTECTED]> wrote: > > On Fri, 19 Aug 2005, Amos Shapira wrote: > > > On 8/19/05, guy keren <[EMAIL PROTECTED]> wrote: > > > actually, it _looks_ like gettimeofday() sometimes takes less then a > > > micro-second to execute. i tested it a few years ago on redhat 7.3,

Re: It's about time: a delay of 1 microsec in a user space

2005-08-18 Thread guy keren
On Fri, 19 Aug 2005, Amos Shapira wrote: > On 8/19/05, guy keren <[EMAIL PROTECTED]> wrote: > > actually, it _looks_ like gettimeofday() sometimes takes less then a > > micro-second to execute. i tested it a few years ago on redhat 7.3, on a > > pentium 1.8MHz and an AMD athlon 2200+, and on both

Re: It's about time: a delay of 1 microsec in a user space

2005-08-18 Thread Geoffrey S. Mendelson
On Fri, Aug 19, 2005 at 08:09:57AM +1000, Amos Shapira wrote: > I'm not sure this is a correct way to measure - gettimeofday(2)'s *interface > definition* is to count nanoseconds, but that doesn't mean that the system's > clock can measure at this resolution. Don't forget that clock interupts are

Re: It's about time: a delay of 1 microsec in a user space

2005-08-18 Thread Amos Shapira
On 8/19/05, guy keren <[EMAIL PROTECTED]> wrote: > actually, it _looks_ like gettimeofday() sometimes takes less then a > micro-second to execute. i tested it a few years ago on redhat 7.3, on a > pentium 1.8MHz and an AMD athlon 2200+, and on both of them running > gettimeofday in a tight loop ver

Re: It's about time: a delay of 1 microsec in a user space

2005-08-18 Thread Matan Ziv-Av
On Thu, 18 Aug 2005, Rafi Gordon wrote: Hello, Is there a way to create a delay of 1 microsec in a user space applcation in 2.4 or 2.6 kernel? What you want is posix high resolution timers kernel patch. http://high-res-timers.sf.net -- Matan Ziv-Av. [EMAIL PROTECTED

Re: It's about time: a delay of 1 microsec in a user space

2005-08-18 Thread guy keren
On Thu, 18 Aug 2005, Gilad Ben-Yossef wrote: > Rafi Gordon wrote: > > Hello, > > > > Is there a way to create a delay of 1 microsec in a user space > > applcation in 2.4 > > or 2.6 kernel? > > If you really meant 1 microsecond (as opposed to 1 millisecond) then the > answer is to do a busy wait l

Re: It's about time: a delay of 1 microsec in a user space

2005-08-18 Thread Peter
Use SCHED_FIFO and it will work. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]

Re: It's about time: a delay of 1 microsec in a user space

2005-08-18 Thread Gilad Ben-Yossef
Rafi Gordon wrote: Hello, Is there a way to create a delay of 1 microsec in a user space applcation in 2.4 or 2.6 kernel? If you really meant 1 microsecond (as opposed to 1 millisecond) then the answer is to do a busy wait loop for the duration of the time required. Any system call will ta

It's about time: a delay of 1 microsec in a user space

2005-08-18 Thread Rafi Gordon
Hello, Is there a way to create a delay of 1 microsec in a user space applcation in 2.4 or 2.6 kernel? I had tried using nanosleep() or usleep() and got ,when doing it in a loop,results which are on the average really much higher than 1 microsec. man nanosleep on RH9 says: The current impl