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.