On Tue, Aug 7, 2012 at 9:12 AM, <mle...@ripnet.com> wrote: > ** > > On 06 Aug 2012 17:59, Alex Zhang wrote: > > Just state, I was using the tunnel.py instead of the rawOFDM to do the > test. Seems nobody declared good bitrate within this community, although I > have asked for many times. > > > > -- > > Alex, > *Dreams can come true – just believe.* > > Nobody has answered because there is no single answer. Your achievable > performance depends on too many factors for anyone to come up with a > reasonable answer. > Yes, I agree with you that there are many factors to impact the performance. So I keep asking what is the best performance has been achieved within the community, and then I can compare with them to find out the possible space to improve the bandwidth supported. What I just need is just an concrete number for benchmark. If any guy claims the good result, I will know I still can do something to beat the limit.
> Different computers, with very different performance levels, different OS > distributions with different optimizations in different parts of the > kernel. And that's ignoring any of the path distortions that may be > present between your radios. > > The fact is that general-purpose operating systems aren't well-optimized > for real-time, high-bandwidth, digital signal processing, even on systems > where the "raw" compute power would seem to be adequate. The path lengths > (in terms of number of executed instructions) between data sources and the > calculations are much longer than they would be in a compute environment > optimized for the job. > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Alex, *Dreams can come true – just believe.*
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
