Re: [Discuss-gnuradio] End-to-end delay question

[Michael Dickens]

On May 22, 2007, at 12:28 AM, Eric Blossom wrote:
> The priority is set to the midpoint of the FIFO range, not maximized.

My bad on the "maximized" ... but ... ummm ... no, not the midpoint  
either the way it's written, if I understand the function calls  
correctly.  Here's the line:

  int pri = (sched_get_priority_max (policy) -  
sched_get_priority_min (policy)) / 2;

The midpoint would be (... + ...) / 2.  ;)

> I don't think we want to be creating new threads just to try
> to set real time scheduling.

These changes are made to the current running thread, not to a new  
thread, just like the code in "gr_realtime.cc".  IMHO GNU Radio  
already has enough threads, especially on OSX's implementation  
because of Apple's weirdness of requiring separate threads for  
callbacks on Audio and USB.

> I strongly suspect that if a pthread
> implementation supports pthread_attr_setschedpolicy with SCHED_RR or
> SCHED_FIFO, then they will also implement sched_setscheduler with
> SCHED_RR or SCHED_FIFO.

On OSX 10.4.9 (and, I would presume any 10.4.X):  
sched_get_priority_max(), sched_get_priority_min (), SCHED_FIFO, and  
"struct sched_param" [and "struct sched_param".sched_priority] are  
defined in standard header files in /usr/include and seem to work as  
required for modifying the scheduling priority and policy.   
Strangely, the only part that's missing from headers is  
sched_setscheduler() ... which gets divided and renamed to  
pthread_attr_setschedpolicy() and pthread_attr_setschedparam().

I've tested out these pthread calls, and they work quite nicely w/o  
needs for su or root execution.  Shouldn't be difficult to create an  
"#elif" condition in gr_realtime.cc for those with pthreads ... but  
first the config m4 script for pthreads needs to work (at least on  
OSX): config.h has "/* #undef HAVE_PTHREAD */" ... I will look into  
these. - MLD