4

The idea: We have an imaging system generating about 200-300 Mb/s of data that currently is passed over an ethernet cable to a computer which decompresses them and displays the live image.

We are trying to make the system wireless over a LAN by having the system pass packets over the ethernet cable to a router which will then broadcast the udp packets to the computer (or eventually-multiple computers).

At the highest level it looks a bit like this:

Before: Imaging device -> cat-5 -> computer (works just fine at up to the required 300 Mb/s)

After: Imaging device -> cat-5 -> router -> 802.11ac wireless -> computer (huge (50%+) data loss past 5Mb/s)

-Computer: surface pro 3

-Router: A Buffalo AirStation AC 1750 DD‑WRT Wireless Firmware: DD-WRT v24SP2- (03/24/14) std

The problem: When we connected the system we found that when we turned up the bandwidth to past about 5Mb/s the packet loss started increasing and the GUI for the router becomes unresponsive.

Knowing that the problem is unlikely to be at either end, we tried configuring the router settings in a variety of ways, disabling the firewall, lowering the UDP timeout, etc to improve the performance. The best configuration we were able to find got us to about 7Mb/s before things rapidly deteriorated.

The surprise: Happened when we replaced the imaging device with a second computer and did a simple file sharing test. When doing a file sharing test (windows computer -> cat-5 -> router -> 802.11ac wireless -> windows computer) with a 2.4GB file we found that we were getting transfer speeds up to 300 Mb/s and that the router GUI was also not freezing.

The only change, near as we can tell, was the communication type and packet size. Because of the complexity of implementing TCP on the FPGA and because we intend to eventually allow multiple end points for the data on a LAN we thought UDP broadcast (1092b sized packets) would work. The other test setup, according to wireshark, was using TCP (1514b sized packets).

The question: Why is the router able to handle TCP with a throughput of 300Mb/s but can't handle a UDP broadcast of more than 10Mb/s? Any thoughts or advice on how to configure the system/router for high UDP throughput on a LAN?

Other notes:

The router was about 5 feet from the computer, transmitting 80Mhz on 5Ghz in both cases.

Update:

As suggested, I tried testing if connecting system over ethernet through the LAN ports would work. This way I was able to get up to 150Mb/s. (imaging system-> ethernet (LAN Port) -> router -> ethernet (LAN Port) -> Surface pro 3)

This suggests to me that the problem is in the router, somewhere between the wireless antenna and the LAN port. Something about how the UDP packets get moved internally to be broadcast is slowing down the process. Which again is interesting because TCP packets were flowing from LAN to wireless just fine. Any thoughts?

branch
  • 41
  • 1
  • 4
  • 1
    When using broadcast and multicast (a form of broadcast) on Wi-Fi, it will only be sent at the lowest speed on the WAP. – Ron Maupin Jun 08 '16 at 03:03
  • Can you take the wireless part out of the equation to check if the bottleneck is there? – cnicutar Jun 08 '16 at 17:25
  • @cnicutar thanks for your comment, I have updated the post to reflect that I tried a LAN to LAN connection through the router and it seemed to work just fine. Any idea why it would have a problem moving the UDP data to the wireless port? (I don't think it is the wireless portion of the connection because A: The theoretical limits are much higher and B: I was able to get 300Mb/s throughput with TCP on the same wireless connection) – branch Jun 09 '16 at 13:40
  • I don't pretend to understand Ron Maupin's comment but.. can you use unicast as a test? – cnicutar Jun 09 '16 at 13:47
  • 2
    It really has nothing to do with TCP or UDP. The problem is that Wi-Fi will send broadcasts at the lowest speed of the WAP. you can't send broadcasts at the highest Wi-Fi speed. For instance, if your WAP's lowest speed it 1 Mbps, but the network nominally runs at 100 Mbps, broadcasts will be sent at 1 Mbps. Broadcasts are not the best way to do things, and IPv6 has eliminated broadcasts, so code using broadcasts will not work with IPv6. – Ron Maupin Jun 09 '16 at 14:26
  • Thanks to you both, we are going to look into testing unicast and will update with results. Do you know a way to turn off the limits on broadcast? Or why it is set so much slower? We'd like to be able to use the functionality that broadcast provides to have more devices listening to the same datastream. – branch Jun 09 '16 at 14:50
  • 1
    About the only thing you can do is to set the lowest speed on the WAPs higher. Not all the devices support this, and you could end up blocking some clients. If you need to do something like broadcasts, you will be better off using multicast. Multicast is compatible with both IPv4 and IPv6, and it will not interrupt clients not needing to receive the traffic, while broadcast interrupts every device on the LAN, including the network equipment. It will have the same problem as broadcast on Wi-Fi, but that is a limitation of Wi-Fi. – Ron Maupin Jun 09 '16 at 20:19
  • There is a good answer [here](http://superuser.com/questions/695813/wifi-udp-unicast-vs-multicast-speed) on [su]. – Ron Maupin Jun 10 '16 at 01:14

1 Answers1

2

Don't use broadcasts over WiFi if you care about performance. Use unicast. Modern WiFi networks are not an effective broadcast medium because all of the advanced optimizations they use to achieve reasonable performance involve the transmitter knowing the receiver's location and capabilities. For an obvious example, think about a dual-band router with MIMO and beamforming. How will those technologies work for a broadcast?

David Schwartz
  • 179,497
  • 17
  • 214
  • 278