CC3120BOOST: Back-to-Back Packet Transfers using UDP are Really Slow

if the air is very congested, or the ap is far (or there are interference) transmission may be delayed and the NWP buffers will fill up and cause new transmissions to block.

if you can get an air sniffer log we might be able to assist. 16 Mbs was achieved in an RF chamber (without any interference). in open air the throughput should be lower but 200Kbps indicates that environment is very problematic.

are you using a launchpad or a customized solution?

what SP and SDK are installed?

Hey Kobi:

Thanks for responding.  I am testing this in my basement of my home and the WAP (Netgear) is only 3 feet away from the CC3120 BP.  There is my DSL router that is about 15 feet away and on the main floor of my home and a Netgear Orbi Mesh device about 8 feet away and that's it.  There is nothing going on in my home when I am doing testing so no WiFi streaming or internet browsing.  Just me running this test.  I have tried using the Orbi Mesh device and the Netgear WAP independently and in both cases, I get the same result - the host gets blocked after transferring 37 UDP packets and can sustain only around 200ish Kbps.

I am using this CC1320 BP:

https://tisamples.ti.com/order/tisamples/en/p/product/?p=CC3120BOOST

and this MSP432E4 LP:

https://www.ti.com/tool/MSP-EXP432E401Y?keyMatch=MSP432E401Y%20LAUNCHPAD

with a direct connection between the LP and BP.  Below is a picture of the setup showing the connection between the LP and BP:

This only applies when I perform the UDP transfer to an IP address that is within my subnet.  If I change my UDP address that is not in my subnet, then this problem goes away - I am able to sustain a data transfer rate of over 9+ Mbps.  Can you explain why this condition would happen only when I use an IP address that is within my subnet but is not the case otherwise?

Thanks,
Tim

Hey Kobi:

I am using SDK v4.20 LP with my MSP432E4 and WiFi plugin v4.20 for the CC3120 BP.

Tim

If the problem is only in the LAN it can be related to the receiver. 

Anyway a connection in the LAN should be slower: when you send a packet over the WLAN network to the AP the AP forward it to the target (so each packet is transmitted twice). If there are re-transmissions between the AP and the target - the throughput will drop. An air sniffer log (you'll need wireshark sw + wi-fi dongle. In some laptops, the wireshark can work with the onboard wi-fi) will help us understand the issue.

Hey Kobi:

A connection to the LAN?  Since I am not using TCP, but transmitting UDP packets, how does the WAP cause the CC3120 to back off from transmissions when moving UDP packets?  Does this make sense to you?   Not clear to me why this backing off of the transmission of UDP packets occur when the UDP address is within the subnet and does not occur otherwise.

Do you know if these TI laptops will allow me to use Wireshark to sniff on these UDP packets or do I need a WiFi dongle?  If so, is there a WiFi dongle you can recommend to use?

Thanks,
Tim

I'm not sure about TI laptops.

I think that even if the laptop has a supported Wi-Fi adapter there are more chances Wireshark will work with Linux driver then the Window's one.

As i said the AP can be the bottleneck that prevents the device from transmitting and emptying the internal buffers (even UDP frames requires L2 ACK from the AP, the 802.11 MAC doesn't differentiate between TCP and UDP frames). But we will need more data from the sniffer.

we are using wlanpi (wlan-pi.github.io/.../).

Hey Kobi:

So if the transmitter is sending UDP packets to a receiver, does the receiver being there or not have any bearing on the data throughput?  I didn't realize there were ACKs going on between the transmitter and the WAP during the transmission of UDP packets.  Does this also apply to the receiver?  So if the receiver is not connected to the WAP, would this have any bearing on the UDP data throughput of the transmitter?

Thanks,
Tim

The ACKs are in is in the 802.11 layer. not in the transport (UDP) layer. This is true between the source station and the AP and between the AP to destination station.

As i mentioned before there should be some degradation in performance inside the local network (due to the packed being repeated by the AP over the same channel) but nothing explains the level of degradation you are seeing. Hopefully the sniffer logs will help us to find the root cause. 

Hey Kobi:

Because UDP is a connectionless protocol and since I was doing a simple test of sending dummy packets, I assumed I didn't need to have the receiver connected to the WAP.  So the transmitter was just sending back-to-back UDP packets to a receiver that was not there.  Once I connected the receiver to the WAP, the problem went away, I was able to sustain back-to-back UDP packet transfers indefinitely at a rate of upwards of 13+ Mbps with a 1356 byte payload.  Does this make sense what is going on here?

Thanks,
Tim

As i told you the problem doesn't seem to be in the UDP level but in the physical/MAC layer.

Let us check the sniffer log to try to understand the problem.

Hey Kobi:

I assume the problem is fixed by having the UDP receiver connected to the WAP.  When doing this test with a WAP, I need to have a valid connection with the receiver of the UDP packets, otherwise the WAP will send a message to the UDP transmitter to hold off the sending of packets until some timeout occurs.  Is that not the case?

Thanks,
Tim

I guess the AP can block the transmitter if he can't find the receiver (address) thus can't forward the message.