The single-core performance of an i5 at 2.4GHz is roughly 8GFlops.
That sounds like a lot, but keep in mind that every sample is *touched* a *lot* in the average case. Every sample has to percolate through layers of kernel, network/USB-stack, and C library, and Gnu Radio. So at 50Msps, it doesn't take long until you've burned up your CPUs capability. And 2.4GHz isn't a particularly fast CPU these days, and there are asymmetries in the integer vs float-point performance on CPUs. Your samples are being handled by a mixture of floating-point and integer pipelines, so even though you may have enough floating-point "headroom", you might be running out of steam on the integer side. It's simply not practically possible to squeeze every last possible milligram of performance out of a modern CPU, using a general-purpose operating system, C libraries, etc, etc. They each optimize for different things, and the composite result isn't necessarily ideal for real-time signal processing. Gnu Radio has made progress lately on improving floating-point performance by using vectorized processing "kernels" for a number of key core functions within Gnu Radio. That helps. But since those blocks (and Gnu Radio) are only *part* of the whole "story" when it comes to processing your samples, the net effect isn't going to be spectacular. On Mon, 05 Mar 2012 08:28:17 -0800, Josh Blum wrote: > 50 Msps is serious amount of data to push through your computer. More > than a feeling, even the most serious computers can easily have a > bottleneck. I suspect that the gnuradio core signal source cannot > sustain 50Msps in 1 thread/1 work function.
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
