3

I have a wireless network setup like this:

Laptop \  |     Wifi Router A       |     Wifi Router B        |  Wifi Router C |
        \ |     /             \     |     /              \     |   /       \    |
         \|wlan0              wlan1----wlan0            wlan1-----wlan0   eth0--|
          |hostapd     managed mode | hostapd    managed mode  |  AP    Internet|

So basically a straight line of laptop -> router A -> router B -> router C -> internet.

Routers A and B have two 802.11a radios in them and are embedded linux boards with high-power radios (Ubiquiti 600mW). Router C is a Linksys E2500 and connects to the Internet via ethernet. There is no bridging being used, only simple IP routing.

All wifi connections have great signals (at least -60dBm) and very low noise (-99dBm).

For speed testing I am using iperf with a large window size (3MB) and 10 parallel connections, with varying transmit times of 100-240 seconds.

The laptop consistently gets results of 6-8mbps between it and router B (upload and download). I have tried many different setting changes on the wifi side and nothing seems to impact the performance, I even checked things like hardware receive/checksum offloading on the interfaces and those settings do not make a difference either.

However, if I test between the laptop and router A, I get around 30mbps. Testing between router A and router B is also well over 25mbps. But when the laptop must traverse more than one radio, the performance is very bad (6-8mbps). I tested my theory by replacing the link between router A and router B with an ethernet cable, and then the speed tests from the laptop to router B more than doubled, to 25-28mbps consistently.

Why is the performance so bad when packets are sent across more than one radio in a router?

Updated:

What I'm trying to achieve is the end-user client network performance (the laptop) that I gain when connecting the AP's with ethernet... without doing so.

I realize that wifi is half-duplex and the more radios there are in the chain, the worse performance will be.

Is it possible to use seprate radios for transmit and receive to solve the problem?

I have 4 mini-pci slots in each board.

Tom O'Connor
  • 27,440
  • 10
  • 72
  • 148
bparker
  • 133
  • 6
  • I'm going to take a guess here, but is there any chance that one of the Wifi radios sits on the USB Host bus on the router? That would cause significant impact. – Tom O'Connor Aug 06 '13 at 07:20
  • A similar but variant thought is that perhaps the two wifi radios on the same router share interrupts, and probably shouldn't, as the bus isn't capable of handling them. – Tom O'Connor Aug 06 '13 at 07:20
  • 2
    Is there a *really* good reason why you're doing it this way? – Tom O'Connor Aug 06 '13 at 07:24
  • All of the devices are too far apart to see more than one device, they are physically in a straight line... think city-level metro wifi. How else would this be accomplished? – bparker Aug 06 '13 at 08:10
  • Metro ethernet. – Tom O'Connor Aug 06 '13 at 08:29
  • The router does not have USB, only a Mini-PCI (not mini-pcie) bus. Unfortunately metro ethernet is not an option in this town. – bparker Aug 06 '13 at 08:38
  • How about point-to-point free-space optics, or PtP microwave radio? – Tom O'Connor Aug 06 '13 at 08:39

2 Answers2

3

Of course the performance will be degraded after so many traversals. Radio is a shared medium (half-duplex), collisions can happen and to avoid them Wi-Fi uses CSMA/CA. Your performance will at least be degraded more than in half. Every client adds to the latency

Alex
  • 516
  • 1
  • 7
  • 18
  • Each access point is on a different non-overlapping channel and only has one associated client. Why would the performance be degraded in this case? What is causing the collisions if there's nothing to collide with? ifconfig also shows zero collisions on all interfaces. Separating the dual-radio routers into two single-radio routers (connected via ethernet) also solved the performance problem. I don't think there's any collisions... there's just something going wrong when two radios happen to be inside one board for some reason. – bparker Aug 06 '13 at 07:39
  • Yes there are not any collisions, thanks to CSMA/CA. APs communicating between each other operate at half-duplex (only one device can place a signal on the media at a given time and others WAIT) thus reducing throughput in half (@minimum). – Alex Aug 06 '13 at 07:47
  • How is CSMA/CA relevant here? There's only one device on each radio anyways. In a dual-radio setup the two radios aren't actually talking directly to each other, their packets traverse the local bus to the CPU, where the kernel handles the routing between the two. Why putting an ethernet cable between the two radios solves all the problems is still a mystery. – bparker Aug 06 '13 at 07:57
  • Aren't you forgetting about the radio link between APs? (in that case it isn't one device, but two). That's where the bottleneck is. I'm not talking about two radios on the same AP, lol. That makes no sense – Alex Aug 06 '13 at 08:02
  • No... all the APs still only have one associated client. For example the radio link between APs (let's say the client radio on router A) should not interfere with the link between the laptop and the AP radio of router A, as they are physically separate... the kernel is always separating the radios and they are only ever talking to one client ever. – bparker Aug 06 '13 at 08:07
  • Oh, nvm.. You really should do more research about how ethernet and wireless LAN communications work – Alex Aug 06 '13 at 08:11
  • So basically I just have to separate all my radios with ethernet connections to fix the performance? – bparker Aug 06 '13 at 08:20
  • It would be better if you interconnected the APs using a switch, I think, and not trying to mess with daisy chaining the APs which is a really bad practice. That's mostly done in outdoor mesh wi-fi environments where you would really have difficulties to connect every AP using ethernet – Alex Aug 06 '13 at 08:25
  • This is exactly an outdoor wi-fi environment, just not mesh... there are several miles between each link. – bparker Aug 07 '13 at 04:11
0

I don't think it's feasible to separate one radio board to be Tx and one to be Rx, because that would result in a huge amount of traffic across the PCI backplane.

Similarly, I suspect that for whatever reason, a lot of the problems are caused by lots of traffic across said backplane already, resulting in what you percieve as latency.

If I were designing a similar system (I do wireless networks for a living [kinda]).. I'd separate the link radios, in other words, Inbound and Outbound pairs, per building into separate physical boxes, connected back-to-back by gigabit ethernet.

That would have the effect of allowing the network adapters, and network hardware to handle the inter-radio, intra-AP traffic, which I suspect may be the bottleneck. Without more information, it's hard to actually make a good diagnosis. It's also hard to ask for whichever information, because frankly, I don't know. That old adage of, you don't know what you're looking for, but will when you find it.

That said, I don't know whether these router boards expose statistics on backplane traffic volumes and so on.

Alex has a few salient points too, although I'm unconvinced about CSMA/CA (Shouldn't it be /CD?), but it's always a possibility. Wireless communication is by its very nature, lossy, and repeating a signal like this is not unlike photocopying a photocopy, or cloning a VHS tape (Remember those? ;).

To recap, I generally don't like the idea of having two radios on the same board, and would try separating them into different physical devices, interconnected by ethernet.

YMMV.

Tom O'Connor
  • 27,440
  • 10
  • 72
  • 148
  • I highly doubt it is a bus limitation, there is only one client across this network and the most throughput they use is 20mbps. I know it's totally feasible to have separate tx/rx radios because Mikrotik does it with their Nstreme Dual feature and it actually works very well, it greatly reduces the problems I'm seeing here, I just can't use their software for this application. – bparker Aug 09 '13 at 18:05
  • Everything has to go through the bus to be processed by the kernel. And 20Mb is nothing even for the cheapest networking SoCs. – Zdenek Jun 16 '19 at 10:17