Re: [Discuss-gnuradio] SCHED_FIFO and NPTL

[Eric Blossom]

On Wed, Mar 08, 2006 at 09:46:54AM -0500, Frank Brickle wrote:
> Eric Blossom wrote:
> 
> >>Bottom line, it hasn't actually been proved that running SCHED_FIFO will 
> >>squash the existing latency and continuity problems, so I'm not at all 
> >>sure much is missing without that capability.
> >
> >
> >Frank, is this a statement or a question?
> 
> It's a statement. I don't have any real proof at the moment but I 
> suspect SCHED_FIFO is a bit of a red herring. I haven't got proof 
> because the couple of times I tried to actually measure a difference I 
> tripped over additional activity that needed to be accounted for, like, 
> for example, periodic journaling filesystem updates.

I've been screwed by ext3 journaling in the past.  We may want to
experiment with Reiser and/or XFS.  I can understand why journaling
would stop filesystem activity, but there's no good reason for it to
suck down all CPU (or go non-preemtable).

> The other unfortunate consequence was that some kinds of X action on the 
> desktop, like switching between multiple desktops, would get deferred -- 
> it got real sluggish -- and then all the display activity would happen 
> in a burst. Sometimes that would choke the audio worse than an 
> occasional xrun. Oh, and the interaction with audio subsystem buffer 
> sizes was unpredictable.

Hmmm.  If the "real time" code is using, say 50% of the CPU, and is
doing it in small quanta, this *shouldn't* be a problem.

> I'm suggesting that the current non-RT scheduling is very delicately 
> balanced and there's no single, universal fix.

Could be.

> What's more, I conjecture that the worst culprit is disk activity,
> specifically paging, and that the cost/benefit fix for that is
> running off ramdisk :-)

The paging problem is fixable with mlock.

  address@hidden doc]$ size /usr/local/lib/libgnuradio-core.so 
/usr/local/lib/libusrp.so
     text    data     bss     dec     hex filename
  1175774   32952    1660 1210386  127812 /usr/local/lib/libgnuradio-core.so
    96999    1916    1044   99959   18677 /usr/local/lib/libusrp.so

The total code + statically allocated data is under 2MB.  If we also
locked down the buffers and the top 1MB of each stack, I think we'd
eliminate that problem.  I could also ensure that the C++ "new"
allocator allocated from an mlock'd area.  (This only happens at
startup.)  No need to worry about the 10's of MB of Python, it's not
on the critical path.  The signal processing code never blocks waiting
for it.  And RAM is currently running at about $100/GB ;)

> It would be *wonderful* to be wrong about this. As I said, it's just a 
> strong hunch.
> 
> >I'm not sure if the JACK FAQ is up to date or not.
> 
> Usually not :-)
> 
> >Do you have data
> >on the success or failure of folks running JACK on ALSA using NPTL and
> >if they are able to get sufficiently good performance?  I guess Ardour
> >users would be a good test case.  How about the dttsp stuff under Linux?
> 
> Again, it ain't conclusive, but it looks like xruns are not a problem 
> with DttSP under Linux. You're absolutely right, Ardour users are the 
> ones to ask. I finally have it installed here and can check it out first 
> hand, at long last.

Let me know what you find out!

Eric