many thanks On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller <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> > 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>marcus.muel...@ettus.com> wrote: >> >>> Hi, >>> >>> On 21.03.2016 01 <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 >>> 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 >> 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 > 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 Cell Phone: 009647504690060 Office Phone: 00964662554683
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
