Falrath41 wrote

These APs work amazing however, the main issue I have with these are that they are advertised with up to 300 mbps throughput, but the ethernet jack is only a 10/100 which means you can talk to the AP at 300 but only receive data at 100.

Sorry, that's wrong. Pharos devices transmit at wireless speeds up to 300 Mbps in 802.11n mode.

First of all, WiFi is a half-duplex medium. There can be only one sender at a time (let's ignore MU-MIMO devices for the moment). This means a CPE is either sending data or receiving data, but not both. People often oversee this fact.

Second, WiFi transmission adds a significant protocol overhead. In 802.11b/g this overhead is ~50%, in 802.11n the overhead is ~30% of the wireless speed. Let's assume you configured the CPE with 802.11n-only. Real data (the »goodput«) is 300 Mbps - 90 Mbps = 210 Mbps, still half-duplex.

Ethernet 100BASE-T is a full-duplex medium. This means the CPE can send and receive over the Ethernet port with 100 Mbps at the same time, thus achieving a total (theoretical) throughput of 200 Mbps, including protocol overhead. To get 2x 100 Mbps data over the half-duplex wireless link, the device must send WiFi frames with 300 Mbps wireless speed at least.

Thus, a Gigabit interface would not gain more speed with current Pharos devices, it would still be 200 Mbps (HD) / 100 Mbps (FD) only.

A true Gigabit device would need to support 802.11ac to make use of the speed a 1000BASE-T interface can achieve.

BTW: next limiting factor is AirTime (shared medium, remember?). Wireless speed and goodput will dramatically drop if the frequency band is overcrowded. That's why a CPE210 performs much worser regarding its goodput than a CPE510 on the very same distance if there are many nearby APs also using the 2.4 GHz frequency band.

See this story for real-world throughput/goodput you can achieve with a CPE510 (goodput with a CPE210 dropped to 3 Mbps on the same WiFi link described in the story due to ~140 nearby APs in the 2.4 GHz band visible to the CPE).

@forrest, please can you move the thread to Wireless Broadband forum? Thanks very much!

@Falrath41, you completely forgot the TCP/IP handshake. If you send 100 Mbps in one direction, there is also traffic in the reverse direction caused by ACK packets (unless it's UDP). While on Ethernet receiving acknowledgements happens at the same time, on wireless links this requires changing the direction of the sender/receiver. You can see this in serious speed tests which measure the bufferbloat aka »lag«.

Falrath41 wrote

In your example, that is like saying a car can drive 100 mph in forward and 100 mph in reverse thus it goes 200 mph... but it doesn't. It can only go 100 mph max in 1 direction.

A much better comparison would be two trains driving on two separate rail tracks (full-duplex). Both need the same time to go from point A to point B and thus use the same speed, but they can carry twice as many people (data) from A to B and vice versa. If there is one rail track only (half-duplex), one train needs to wait until the other arrived before it can use the same rails. It would need twice the time in total to carry the same amount of people from points A to B and B to A, not accounting for delays if cows are crossing the rails (other APs).

Car comparisons always suck. 

What's more, I didn't talk about 802.11b/g. But let's do so: any AP using the same frequency channel as the CPE, but using slow speeds up to 54 Mbps will require even more AirTime than a 802.11n device, thus limiting the CPE's throughput even more by stealing AirTime from the CPE, which listens for silence before it starts talking (LBT, part of CSMA/CA WiFi protocol). This is the bottleneck, not the 100BASE-T interface.

And max. speed for 802.11n is 150 Mbps, you can reach 300 Mbps only if using 2×2 MIMO (what the CPEs do).

Let's assume the Pharos device would have a Gigabit Ethernet interface: it would NOT increase AirTime available for a CPE and it would NOT increase the WiFi speed. If you don't believe, do a speed test with an EAP225, which has a Gigabit interface, and set its WiFi mode to 802.11n.

Read my story linked in the post. We achieved a goodput of 80 to 90 Mbps (full-duplex!) per CPE measured on the router, which is pretty good for a Fast Ethernet interface. We also have figures for other APs and their goodput always correlates to the WiFi speed. Believe it or not, we were able to reach 1,470 Mbps using the 24 GHz (twenty four Gigahertz) band with a bi-directional link at 0ms latency with other devices, but they are also over 30 times as expensive as CPEs while roughly 15 times faster.

Nevertheless, for installations at customer sites which barely can get 50 Mbps or 100 Mbps upstream speed from the ISPs in our country, we prefer to use CPEs.

Falrath41 wrote

The story you referenced also mentions that the speed was limited to the ethernet port speed of only 100 and they hit approximately 115-130 mbps which is less than half of the speeds they were hoping for. So the referenced story also suggests a GBe port.

No, it doesn't (and it's not »they were hoping«, it's me who hopes, builds and organizes this event every year).

You assume that on a 300 Mbps WiFi link you could get 210 Mbps throughput in one direction. This is not the case, at least not if you use bidirectional TCP/IP communication over WiFi. The limiting factors are AirTime and the TCP/IP as well as the WiFi protocol overhead. If you only use UDP and hope to never get an answer back, then you could probably reach better results, but you could not surf the web nor exchange mail nor use many other services requiring bidirectional transmissions.

See the built-in speed test of CPE, which is not using the Ethernet interface at all, but only measures real-world data throughput over WiFi between two CPEs (and this was a lab test before the event with almost ideal conditions, almost no interferences, short distance etc.):

BTW: I'm not from TP-Link – just in case you think so –, but I'm sure the TP-Link engineers know their stuff very well.

Ok, a last try to explain real-world WiFi behavior.

Test setup: MacBookPro, EAP225 AP, 802.11ac-only WiFi mode, 80 MHz channel width, Gigabit interface, ISP speed 400/20 Mbps, speedtest: dslreports.com.

First, a test with profile »Cable« (profile just influences the weighting of the results):

Fine. We got 419/22 Mbps out of 400/20 Mbps, that's cool (ISP does over-provisioning to guarantee the bandwidth).

Now with an EAP225, negotiated WiFi speed is 866.7 Mbps wireless speed, profile is »WISP«:

Can you explain the drop in speed over a Gigabit interface with negotiated wireless speed 866.7 Mbps?

Why is the upload bandwdith roughly unchanged compared to the cable test, but the download bandwidth did significantly drop by 32%? It was uni-directional transfer for downloads and uploads, not bidirectional. According to your theory the speed should be 419 Mbps downstream, right? The AP is capable of this speed, the Gigabit interface is capable of this speed, so why this reduced throughput?

Hint: you can see the reason for the drop of the throughput in the graphs. Now explain why this did happen, please.