discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Discuss-gnuradio] fusb::_reap: Interrupted System Call


From: Jared Jensen
Subject: RE: [Discuss-gnuradio] fusb::_reap: Interrupted System Call
Date: Tue, 16 Oct 2007 12:47:59 -0400

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: address@hidden
> To: address@hidden
> CC: address@hidden
> 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! Get 'em!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]