On Tue, Nov 14, 2006 at 10:04:46PM -0800, Thomas Schmid wrote: > Hi Eric, > > I did new test today, and you were right. I had a lot of underrun. > Therefore, I increase fusb_nbloccks to 8 and fusb_block_size to 2048. > Even with this setting, I got some underruns, but they were not often > at all. Here are the new numbers (for the code in trunk): > Decimation, Nice, Real_Time, mean [s] > 8, 10, no, 0.00058 > 8, -20, no, 0.00057 > 8, -20, yes, 0.00058 > 16, 10, no, 0.00108 > 16, -20, no, 0.00102 > 16, -20, yes, 0.00106 > > Interpret this as a CSV file ;). Nice is the nice value with which the > process run. Real_time means if real time scheduling was enabled or > not. As you can see, these numbers are way better then the ones I had > yesterday. > > Now, here the result for your updated code: > Decimation, Nice, Real_Time, mean [s] > 8, 10, no, 0.000635 > 8, -20, no, 0.000629 > 8, -20, yes, 0.000627 > > As you can see, the new code performs worse. I didn't do more than > these three tests with your code, because I wanted to see a first > result, before I spend more time collecting data. > > Thomas
Interesting. Note that "real time" won't directly impact the the latency, however it should allow you to use smaller values for fusb_nblocks and fusb_block_size without incurring underruns. I'm somewhat surprised that the new code doesn't show less latency. I'll have to think about that some more. When you run out of things to measure, running with real-time, can you try reducing fusb_block_size and fusb_nblocks ;) Can you mail me your complete rx program off the list? Thanks, Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
