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:  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

Reply via email to