system waits and timer granularity

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

system waits and timer granularity

Patrick Stinson
I am running into problems with pthread_mutex_timedlock() and my  
system's (linux, x86) timeout granularity.

In my event loop I've got a bit of code that processes events in the  
real-time loop to control the behavior of my dsp objects. The events  
come in on a special queue, that, on a call to get(), blocks a  
maximum of the amount of time left in the loop period. This behavior  
is implemented using pthread_mutex_timedlock().

In a practical situation, a period could last 1ms. Assuming the dsp  
processing takes 750us, that leaves a little less than 250us for  
processing events. I assume gettimeofday() is fairly accurate within  
these bounds, but sleep methods like select and  
pthread_mutex_timedlock can be accurate to around 10ms in most cases,  
and one second in other cases. Having run some tests, I've found some  
inconsistent results. I used the following code to get an idea of the  
accuracy of pthread_mutex_timedlock().

typedef unsigned long ulong;

ulong msecs(struct timeval start,
             struct timeval end)
{
   ulong secs = end.tv_sec - start.tv_sec;
   ulong usecs = end.tv_usec - start.tv_usec;
   printf("%d %d\n", secs, usecs);
   return secs * 1000 + usecs / 1000;
}

int main()
{
   struct timeval start;
   struct timeval end;

   gettimeofday(&start, 0);
   usleep(500);
   gettimeofday(&end, 0);

   ulong diff = msecs(start, end);
   printf("%d\n", diff);
}

On my powerbook, I get this:

patrickkidd:~ patrickkidd$ gcc time.c
patrickkidd:~ patrickkidd$ ./a.out
0 550
0
patrickkidd:~ patrickkidd$ ./a.out
0 550
0
patrickkidd:~ patrickkidd$ ./a.out
0 10831
10
patrickkidd:~ patrickkidd$ ./a.out
0 4337
4
patrickkidd:~ patrickkidd$ ./a.out
0 546
0
patrickkidd:~ patrickkidd$ ./a.out
0 545
0
patrickkidd:~ patrickkidd$ ./a.out
0 544
0
patrickkidd:~ patrickkidd$


On my gentoo x86 instance, I get this:

patrick@norm ~/tmp $ ./a.out
0 84
0
patrick@norm ~/tmp $ ./a.out
0 107
0
patrick@norm ~/tmp $ ./a.out
0 82
0
patrick@norm ~/tmp $ ./a.out
0 85
0
patrick@norm ~/tmp $ ./a.out
0 84
0
patrick@norm ~/tmp $


Any idea as to why the linux implementation sleeps for considerably  
less than the requested amount? Does anyone have any experience with  
how these methods behave in this context? Given my understanding  
about the system's timer granularity, is my attempt at managing my  
cycles per loop period in vain? Thanks!

-P



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: system waits and timer granularity

Jack O'Quin-2
Patrick Stinson <[hidden email]> writes:

> Any idea as to why the linux implementation sleeps for considerably
> less than the requested amount? Does anyone have any experience with
> how these methods behave in this context? Given my understanding
> about the system's timer granularity, is my attempt at managing my
> cycles per loop period in vain? Thanks!

I'm not sure.  

I've generally found usleep() inaccurate with many Linux kernels.  For
recent 2.6 ones, I've observed it rounding up to the next higher
millisecond.  But, that is not what your program saw.  

So, I really don't know what is going on.
--
  joq


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: system waits and timer granularity

Patrick Stinson
I changed my code a bit (too long for a snip) and found that  
pthread_mutex_timedlock will block for an average of 2ms on my gentoo  
x86 for timeouts below 1ms and above the length of the call itself,  
which was ~20us (causing the timeout to have been passed by the time  
it was evaluated).

So I rest on 2ms for linux, which is unacceptable. My results lead me  
to conclude that managing what the real-time thread spends its time  
on to prevent overruns is impossible in this fashion. nuts.

I guess I'll just call gettimeofday() before each event to decide if  
the loop should stop and go to the next iteration or not.

On Nov 8, 2005, at 3:53 PM, Jack O'Quin wrote:

> Patrick Stinson <[hidden email]> writes:
>
>> Any idea as to why the linux implementation sleeps for considerably
>> less than the requested amount? Does anyone have any experience with
>> how these methods behave in this context? Given my understanding
>> about the system's timer granularity, is my attempt at managing my
>> cycles per loop period in vain? Thanks!
>
> I'm not sure.
>
> I've generally found usleep() inaccurate with many Linux kernels.  For
> recent 2.6 ones, I've observed it rounding up to the next higher
> millisecond.  But, that is not what your program saw.
>
> So, I really don't know what is going on.
> --
>   joq
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.  
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: system waits and timer granularity

Dave Robillard
On Tue, 2005-08-11 at 16:46 -0900, Patrick Stinson wrote:
> I changed my code a bit (too long for a snip) and found that  
> pthread_mutex_timedlock will block for an average of 2ms on my gentoo  
> x86 for timeouts below 1ms and above the length of the call itself,  
> which was ~20us (causing the timeout to have been passed by the time  
> it was evaluated).
>
> So I rest on 2ms for linux, which is unacceptable. My results lead me  
> to conclude that managing what the real-time thread spends its time  
> on to prevent overruns is impossible in this fashion. nuts.

You're calling this in the realtime thread?  Naughty. ;)

-DR-


P.S. please don't top-post.




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: system waits and timer granularity

Dave Cunningham
On Wed, Nov 09, 2005 at 12:59:30PM +1100, Dave Robillard wrote:

>On Tue, 2005-08-11 at 16:46 -0900, Patrick Stinson wrote:
>> I changed my code a bit (too long for a snip) and found that  
>> pthread_mutex_timedlock will block for an average of 2ms on my gentoo  
>> x86 for timeouts below 1ms and above the length of the call itself,  
>> which was ~20us (causing the timeout to have been passed by the time  
>> it was evaluated).
>>
>> So I rest on 2ms for linux, which is unacceptable. My results lead me  
>> to conclude that managing what the real-time thread spends its time  
>> on to prevent overruns is impossible in this fashion. nuts.
>
>You're calling this in the realtime thread?  Naughty. ;)

What about

clock_gettime(CLOCK_REALTIME, &tp);



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: system waits and timer granularity

Lee Revell
In reply to this post by Patrick Stinson
On Tue, 2005-11-08 at 08:24 -0900, Patrick Stinson wrote:
> I am running into problems with pthread_mutex_timedlock() and my  
> system's (linux, x86) timeout granularity.

Need to know kernel versions for both systems.

Lee




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: system waits and timer granularity

Lee Revell
Please don't trim CC lists, use reply to all for all list messages.

On Wed, 2005-11-09 at 16:29 -0900, Patrick Stinson wrote:
> 2.6.12 is the only linux kernel I run. I have one box, its an athalon  
> XP2400+ with a via board.
>

But you said you have a Powerbook too.  What kernel is running on that?

Lee

>
> On Nov 9, 2005, at 2:05 PM, Lee Revell wrote:
>
> > On Tue, 2005-11-08 at 08:24 -0900, Patrick Stinson wrote:
> >> I am running into problems with pthread_mutex_timedlock() and my
> >> system's (linux, x86) timeout granularity.
> >
> > Need to know kernel versions for both systems.
> >
> > Lee
> >
> >
>
>



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel