discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Large RX Delay


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Large RX Delay
Date: Tue, 14 Nov 2006 23:08:53 -0800
User-agent: Mutt/1.5.9i

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




reply via email to

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