Note that the benchmark_rx/_tx example is really a bit old, and I always try to steer people away from it towards the newer OFDM examples that are far more flexible and behave a lot more like a real system would.
Have a look at the ofdm_loopback.grc example; you can replace the (channelmodel->throttle) by a USRP sink and source. Tadah! Live demo. Best regards, Marcus On 21.03.2016 11:34, Diyar Muhammed wrote: > many thanks > > On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: > > Diyar, > > > I look at tx benchmark help I could not find rates but there is > packet size and megabytes to transmit. > > benchmark_tx --help should help you. > You set the bandwidth, which sets the sampling rate; together with > the occupied tones number related to the FFT length, you get a > symbol rate. > Together with the modulation you set, this gives you a > > Since only one program can use a USRP at a time, you can't use > benchmark_tx and benchmark_rx at the same time. > Instead, use benchmark_tx with the "--to-file" option to save the > samples to a file, and build a quick GNU Radio flow graph in GRC > that has a file source (reading that file), a USRP sink (fed from > the file source), a USRP source, and a file sink (saving the > samples from the USRP source to another file). > > Then use benchmark_rx with the --from-file option to read in these > saved samples. > > Best regards, > Marcus > > > On 21.03.2016 11:17, Diyar Muhammed wrote: >> Dear Marcus, >> Thank you very much indeed for fast replying. >> I look at tx benchmark help I could not find rates but there is >> packet size and megabytes to transmit. >> so that, which one do you mean packet size or megabytes? >> it is okay to use USRP B210 for transmitting and receiving by >> using to benchmark file? >> because when I used one of them (tx or rx) and then I wanted to >> run another one the error come up (no device found for empty >> device address). >> in advance many thanks. >> >> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller >> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: >> >> 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: <http://www.mhe-krg.org/>www.mhe-krg.org >>> <http://www.mhe-krg.org> >>> Cell Phone: 009647504690060 >>> Office Phone: 00964662554683 >> >> >> >> >> -- >> 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 > > > > > -- > 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
