AC3200 - bonding the 5GHz radios in Bridge Mode

[sfx2000]

Anybody try using the Linux Bond Driver to bind the two chipsets yet in Bridge Mode?

Would be interesting to see the two chipsets working together to provide an "AC2600" link...

I just don't have $600 to spare for experimentation...

 

[RMerlin]

Anybody try using the Linux Bond Driver to bind the two chipsets yet in Bridge Mode?

Would be interesting to see the two chipsets working together to provide an "AC2600" link...

I just don't have $600 to spare for experimentation...

It's no more possible than bonding the 2.4 and the 5 GHz channels. Your clients can only connect to one specific channel, and both 5 GHz radios have different channels.

 

[sfx2000]

It's no more possible than bonding the 2.4 and the 5 GHz channels. Your clients can only connect to one specific channel, and both 5 GHz radios have different channels.

Actually - bonding works at the MAC layer, not at the IP layer - I do this stuff all the time at the office, bonding ETH0 to ETH1 as BOND0, and assigning an address to BOND0...

Has to be done on both ends, hence my statement about not having $600 to spare.. but my gut says this is entirely possible with how Broadcom has implemented their chipsets at a kernel level...

Bonding also works for multiple WAN configs, FWIW, and that includes VPN pipes... and there it can be used for load-balancing, along with failover...

 

[sfx2000]

Again, I'm talking about a bridge connection with two AC3200's, not client to AP...

 

[RMerlin]

Again, I'm talking about a bridge connection with two AC3200's, not client to AP...

You'd be bonding the virtual interfaces, not the actual PHY links. The firmware still cannot connect to more than one radio at a time.

It's like having two ports bound on two switches, yet you only plug one single Ethernet cable between them. Your throughput remains 1 Gbps, not 2. You need two separate links to achieve 2 Gbps.

 

[Razor512]

I wonder why can't they allow multiple bands to be used at the same time?

Can't they do it like how a dual WAN for load balancing, of with teaming where a single connection may be limited to the throughput of a single PHY link, but multiple connections can be spread over multiple PHY links. This seems like it would allow for better overall throughput, e.g., 1 radio being used to download 1TB of anime, while another radio is handling your online gaming session.

In its simplest form, why can't we have link aggregation with WiFi?

E.g., using multiple WiFi radios, or Having a an AC3200 device, use both 5GHz radios for a single wireless bridge, or like how dual WAN load balancing can make use of 2 different internet connection speeds, allow the 5GHz, and 2.4GHz band to be used as a bridge.

 

[RMerlin]

I wonder why can't they allow multiple bands to be used at the same time?

Can't they do it like how a dual WAN for load balancing, of with teaming where a single connection may be limited to the throughput of a single PHY link, but multiple connections can be spread over multiple PHY links. This seems like it would allow for better overall throughput, e.g., 1 radio being used to download 1TB of anime, while another radio is handling your online gaming session.

In its simplest form, why can't we have link aggregation with WiFi?

Because the hardware clients are unable to connect on more than one channel at a time, and Windows itself (which represents like 90% of the market) can't connect to more than one wireless AP at a time.

E.g., using multiple WiFi radios, or Having a an AC3200 device, use both 5GHz radios for a single wireless bridge, or like how dual WAN load balancing can make use of 2 different internet connection speeds, allow the 5GHz, and 2.4GHz band to be used as a bridge.

The clean, non-hackish solution to this will come in the form of 160 MHz channels.

 

[sfx2000]

You'd be bonding the virtual interfaces, not the actual PHY links. The firmware still cannot connect to more than one radio at a time.

It's like having two ports bound on two switches, yet you only plug one single Ethernet cable between them. Your throughput remains 1 Gbps, not 2. You need two separate links to achieve 2 Gbps.

I had to re-read your response - I'm not talking about ganging up the radios, but bonding the MAC addresses/virtual interfaces - each radio would still link up with it's peer on the other end wl0 on device A to wl0 on device B, same with the other interface, and then create the bond0 interface across them.

Conversely, one can also do this across bands, or a more practical solution for many, is bond the WAN interfaces (the Linux bonding driver has several options, including, but not limited to load balancing and failover if one drops).

 

[RMerlin]

I had to re-read your response - I'm not talking about ganging up the radios, but bonding the MAC addresses/virtual interfaces - each radio would still link up with it's peer on the other end wl0 on device A to wl0 on device B, same with the other interface, and then create the bond0 interface across them.

Conversely, one can also do this across bands, or a more practical solution for many, is bond the WAN interfaces (the Linux bonding driver has several options, including, but not limited to load balancing and failover if one drops).

I still fail to see what that would bring. You would not end up with an AC2600 link like you mentioned in your first post, it would still be AC1300.

 

[sfx2000]

I still fail to see what that would bring. You would not end up with an AC2600 link like you mentioned in your first post, it would still be AC1300.

Technically, it's two AC1300 links, just bound together, hence the psuedo-AC2600

sfx