Eric,

     Ubuntu, Feisty.  2.6.20-16-generic.  HP dv2000
laptop, Core 2 Duo, 1.6 GHz.  2 GB RAM, 160GB HDD 5400 RPM (But I'm not
doing much disk I/O at all).  

     I get the error message
every 10-15 seconds or so.  Sometimes I won't see it for minutes at a
time, and other times, I'll see it often; like multiple times in a few
seconds.  Like I said, no data is missing (as far as I can tell), but
this pops up frequently; apparently from the libusb driver.  I don't
get overruns, just this.  Also, as I said, I can't see any missing
data, but I also can't 100% guarantee that I'm not losing some data, so
it concerns me a little.

     To reproduce it, I just run my
code.  :)  I've written some custom code to do MSK.  It's all in C++,
since management wasn't down with Python, and I had to interface to our
existing C++ protocol libraries.  (And other complications...)  So I
ported the DBSRX tuning code over to C++, and implemented a read
thread.  Then my consumer thread just takes the data and handles it. 
The read thread is really brief.  It's just a while(1) loop 

while(!bThreadStop){ 
        // Toggling the ping pong buffers
        (!bWhichBuf) ? arr = &array1[0] : arr = &array2[0];
        
        // The read
        nRead = myDev->read(arr,sizeof(array1),&bOverrun);        
            
        // The resampler method just hands the data to my processing thread.
        // The processing thread then handles the polyphase rational resampler.
        if(bUseRationalResampler){
            myDSP->rational(arr,nRead/sizeof(short));
        }
   
    else{  // Or just copy it out and do nothing with it.  (This still
produces the error message.)  I did this to debug if maybe something
                        // was lacking CPU time, or resources.  But it seems 
like the error is independent of processing load.
            myDSP->CopyData(arr,nRead/sizeof(short));
        }
        
        // Keeping track of the amount of data
        nData += nRead/sizeof(short)/2 & ( INDEX_MAX - 1 );
        
        if(bOverrun){
            fprintf(stderr,"DISASTEROUS ERROR : Overrun!  (%ld)\n",nData);
            if(bLogDebugging)
                fprintf(logfileFID,"DISASTEROUS ERROR : Overrun!  
(%ld)\n",nData);
        }
        
        // Switch buffers
        bWhichBuf = !bWhichBuf;
}

So
that's the only code that reads the USRP.  My read thread is MAX
PRIORITY, and it spends most of its time blocked.  My other thread
takes about 15% of the CPU on my machine.  I know that the read thread
resides on one core of my CPU, while the processing is on the other
core.  (Processor affinity from Intel's ICC compiler.)  It always seems
like both threads have more than enough resources though.  But again,
I'd be open to any suggestions/tips/tricks.  It seems like nothing I do
changes it, so let me know if you have any insight and I'll give it a
try.

Also, everything runs well and processes well.  So I'm
talking to the USRP correctly and to the DBSRX correctly as well. 
(Have been for a couple of months now.)  Again, there may be some
subtlety I'm missing, but as for functionality, things appear to work. 


Thanks for the help.

Jared

> Date: Mon, 15 Oct 2007 12:38:28 -0700
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] fusb::_reap: Interrupted System Call
> 
> On Thu, Oct 11, 2007 at 03:54:56PM -0400, Jared Jensen wrote:
> > 
> > Does anyone know why I get "fusb::_reap: Interrupted System Call" fairly 
> > frequently?  There are no overruns, and my data seems good, but I keep 
> > getting this error.  If it's meaningless, is there a way to suppress it?
> > 
> > Jared
> 
> I've never seen it.
> 
> Can you tell me how you reproduce it?
> What OS, distribution, etc?
> 
> Eric

_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to