Low data speed with high bandwidth

bastibl / gr-ieee802-11

IEEE 802.11 a/g/p Transceiver

https://wime-project.net/

GNU General Public License v3.0

750 stars 292 forks source link

Low data speed with high bandwidth #164

Closed rcetin closed 5 years ago

rcetin commented 5 years ago

Hi Bastian, I am trying to communicate two N310s. I am using wifi_transceiver.grc. I have made some changes on grc file;

decreased multiply const to 100m
removed ethernet encapsulation and added LO offset.

It's working now and i can ping other device. It is shown in below.

Then i made a speedtest using iperf3 tool. This is the result.

So, data rate is about 500Kb/s. My bandwidth is 10MHz and modulation is QPSK 3/4. Why is it so slow? Is it related with MTU size? (High MTU sizes causes to crash application)

Best regards.

bastibl commented 5 years ago

I guess this is mainly due to inherent delay/timing limitations of a CPU implementation.

Currently the maximum frame size is hardcoded to 1500 byte. GNU Radio's Tagged Stream block require that the whole frame fits within the input buffer. And a BPSK-1/2 is already quite large. This could be changed if needed, but I don't think that it will make things better.

I assume the main issues are:

TX is not optimized for speed, i.e., it's not possible to send frames at a high rate. (See the related paper https://www.bastibl.net/bib/arcos2016accelerating/ and a recent issue https://github.com/bastibl/gr-ieee802-11/issues/162
Timings are non-deterministic and vary. This can cause TCP to trigger restransmissions, which lower the bandwidth. (I assume you used TCP).

If you want to avoid the latter you could try UDP. But I assume the low of transmitted frames per second might be the main issue.

rcetin commented 5 years ago

Hi Bastian, Thank you for your response. So, i think if i try the optimized TX version, it can increase speed significantly. There is also another problem in this context that i mentioned in issue. Long time high bandwidth transmission freezes gnuradio transmitter side. After it freezed i cannot close it and i have to kill the process. This is the case that i produced that issue:

BW: 10MHz, LO offset: 6M, mod: QPSK 3/4
I run the following command to test my transceivers; iperf3 -c 192.168.200.2 -t 200
After a while speed decreased to 0;
And transmitter side is crashed.

Do you have a idea about what the problem can be in here?

bastibl commented 5 years ago

Can you reproduce this issue with the unmodified version from this repository? Or does that only happen with the "optimized" version?

rcetin commented 5 years ago

I used your version of transmitter. I did not tried optimized version yet. I reproduce that error again. This is my flowgraph of transceiver. My test conditions:

I arrange different frequencies for 2 N310s' RX and TX(5890 and 5860)
LO offset: 6M
mod: QPSK 3/4
multiply const: 100m
BW: 10M After i test pinging (i can ping), start testing interface using iperf3. iperf3 -c 192.168.200.2 -t 200 After a while, transmitter again freezed.

Transmitter log:

Regards.

rcetin commented 5 years ago

Hi Bastian, Update: I am sorry, i misunderstood the situation. Actually the stopped side is receiver side. The green LED on receiver USRP is off. This is receiver log when it is stopped;

After rebooting RX USRP, system starts working. So, transmitter is okay but receiver is freezes after high throughput data transmission for a while.

bastibl commented 5 years ago

At the moment, I don't have the hardware to reproduce this. And in simulations, I never experienced that. Please check the threads to see if it is in an endless loop, if a thread crashed. Maybe enable debugging for some blocks to understand which block causes the problem etc.