discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] OFDM benchmark optimal parameter
Date: Mon, 21 Mar 2016 09:09:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

Hi,

On 21.03.2016 01: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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]