On Tue, Dec 15, 2009 at 8:51 PM, Eric Blossom <[email protected]> wrote: > On Tue, Dec 15, 2009 at 01:01:22AM +0100, Gaetano Mendola wrote: >> Hi all, >> I think I'm experiencing some buffer underrun using an instance of >> usrp2, to transmit my >> samples I'm using the method usrp2::tx_16sc. >> >> I have the usrp2 equipped with a rfx400 and using as interpolation a value >> of 8. >> >> I found out that 192 calls to usrp2::tx_16sc last 0.56 seconds passing >> to it a total of 7104000 >> complex. At my rate 7104000 complex are transmitted in air in a bit >> less than 0.56 seconds >> and it seems I'm very tight in the time I can loose between two >> usrp2::tx_16sc calls. > > At interp = 8, you need to generate 12.5MS/s, so your average rate > looks OK (710400/0.56 = 12.67MS/s), but you'll want to check this > overa longer window, say 10s.
The data I was reporting was an average on 192 calls over more than 20 seconds of transmission. > Have you enabled real time scheduling in your transmitter code? > > #include <gruel/realtime.h> > > gruel::rt_status_t r = gruel::enable_realtime_scheduling(); > if (r != RT_OK) > std::cerr << "Failed to enable realtime scheduling\n"; > > > For this to work, you'll need to be in group "usrp" and will have to add > this line to /etc/security/limits.conf: > > �...@usrp - rtprio 50 That was the next inline activity I had plan to do. >> My questions are: >> .) How do I check if I had a real underrun? > > Right now you can't unless you hook up a cmos-to-serial port converter > to the USRP2. (This is being fixed as part of the VRT work). No idea what VRT is, I will google for it :D >> .) How much time I can loose roughly between two calls to not incur in >> underruns? > > There's a small amount of buffering on the USRP2. It's on the order of > a few ethernet frames. The host needs to pretty much not miss a > beat to keep it fed. At my rate 2 ethernet frames are realy not that much :s >> .) Is there a way to make the tx_16sc async ? > > Sure, put the caller in it's own thread. Or use GNU Radio to talk to > the USRP2. We already do that. The caller is already on his own thread and between the samples producer and the thread calling the tx_16sc I have a double buffered queue that permits small interactions between consumer and producer apart a small window time in where the two buffers are swapped. I have to replace those two queues with a rings in order to eliminate the need to do heap allocations. actualy my caller thread main loop is something like this: 1) samples* p = std::list<samples*>::front; 2) 192 calls of usrp2::tx_16sc(...); 3) delete p; 4) std::list<samples*>::pop_front; I see that the average time between two calls of those192 tx_16sc has some spikes, and those spikes are related to the average time for that delete. I hope that changing the scheduler, and removing the dynamic memory allocation my problem is solved. I'll let you know otherwise :D Thank you for your explanations. Regards Gaetano Mendola -- cpp-today.blogspot.com _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
