Diyar, with the benchmark_ scripts, you **set** the rates, and you can only observe how many packets were successfully transmitted. The rest is really very basic math.
Best regards, Marcus On 21.03.2016 10:50, Diyar Muhammed wrote: > Dear SangHyuk, > I would like to know how to measure Throughput and BER by using > benchmark tx and rx? > could you show or explain with real example as you used. > in advance thanks. > > On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: > > Hi, > > On 21.03.2016 01 <tel:21.03.2016%2001>:37, SangHyuk Kim wrote: > > I want to know other user's performance (avg performance). > Yes, but what is "user's performance"? Is it more important to have > higher throughput, or lower error rates? What about robustness? > > I mean, the OFDM rx_benchmark is a really static example. > You might find a setting that maximizes troughput for a given channel, > but imagine something happens that reduces your receiver's SNR by 3dB: > Now your suddenly losing a lot of performance. > > Really "how can I parameterize this" can only be answered for a > single, > mathematically well-defined target, and for a well-defined channel. > > In a real-world scenario, if using a transceiver with a fixed > modulation, you usually wouldn't maximize throughput for a given > setting, but you would define what "it still works sufficiently" > means, > and then you'd define "the worst channel I want the system to > still work > sufficiently". > Then you'd come up with a metric that gives you a number for "the link > quality on all considerable channels where this should be > working", and > then you'd try to maximize that metric under the outage > constraints set > before. Notice that this metric has to take things like error rate, > throughtput, the "cost" of re-sending something (if you have a > mechanism > for that), available channel coding, how much you care about latency, > computational complexity (that really gets important with iterative > channel decoding), > > In other words: > This is digital communications. If there was a single "best" solution, > we'd all be using that and be done. Use your digital communications > knowledge to analyze your requirements and challenges! > > Best regards > Marcus > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > -- > Regards, > Diyar Muhammed > Ministry of Higher Education and Scientific Research > Duty: Network Administration and Design > Website: www.mhe-krg.org <http://www.mhe-krg.org/> > Cell Phone: 009647504690060 > Office Phone: 00964662554683
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
