..so i bit the bullet and updated my gear (CPE510s) to v2.0.0. Early observations so far:
It appears as though the throughputs are 'similar' across the board, i.e. power outputs / channels / MCS levels, with some rather peculiar findings in between.
First off there's something that's definitely been tweaked in the Unidirectional tests department. As pointed out by R1D2 a few posts back Unidirectional tests previously only included a Tx mode which under my test setup now yields anything from 20-30% higher rates than anything I've seen before, while and the newly introduced Rx mode is close to previously reported values.
And then there's the bidirectional tests that behave somewhat strangely, too...take a look at the screenshots below and see how the graphs are interpreted from the server and client side. Surely the new curvature-algorithm must have something to do with it but i'd expect such peculiarities to pertain presentation-only issues, but the results themselves are considerably up on the Tx and down on the Rx for some strange reason.
So there you have it. In all, the chromatic aesthetic changes of the UI to reflect the logo change, the addition of small bits & pieces here and there (DNSs / VLANs etc) and a few additions in the benchmarks section...at least for me it doesn't really substantiate a 2.0 release unless so much more has changed under-the-hood that I didn't notice. Accessing the Survey window UI from mobile devices remains a pain as it used to be and the new UI colours subjective as it might be leave much to be desired.
Further to my previous report, a couple of things to add...
1. sometimes upon CPE reboot I'm still experiencing Web Server port reset. For example I have the web server running on port 50001 on one CPE and on port 50002 for the next one and so on and so forth for the rest of them...In case of manual and / or ping wachdog reboot there's still a 1 in 3 possibility that the web server resets to port 80 which makes the UI inaccessible from the WAN side and is indeed a bummer to say the least.
2. I have been unable to broadcast having selected Repeater / Bridge / AP Client Router modes. I can only receive and I still can't figure out why. So it's back to AP / client mode **ONLY** for the time being I'm afraid.
3. There's definitely something OFF with Uni - TX results a I'm consistently getting 800Mbps (!!) results that rocket skyhigh to the y-axis values..
Anyone from TP-Link tech support maybe?
Uhm, which y axis? Speed test has no graphical display on my CPE. If you measured it on the status page, which interface did you use?3. There's definitely something OFF with Uni - TX results a I'm consistently getting 800Mbps (!!) results that rocket skyhigh to the y-axis values..
Last edited by R1D2; 03-01-2017 at 14:11.
let us know how it works out for you
...have you actually tried connecting to the repeater or even surveying to see that it broadcasts?!
Again I hate to be the bearer of bad news, but if you happen to have a 5ghz device there somewhere I'd be more than interested to learn the results cause in my case no matter what I can't get the device to broadcast, let alone the remote 3rd CPE picking up anything.
I also can reproduce the spike in statistics you observed, but it is showing correct values:
This correctly shows data speed of packet transfer from built-in iperf (acting on logical interface LAN) to the WiFi network (acting on logical interface WLAN7). See, it is network BRIDGE selected for measuring throughput between LAN and WLAN7.
To measure throughput of data sent over the radio link you need to select logical interface WLAN7, not BRIDGE:
The spike at the beginning is most certainly caused by PharOS buffering data from iperf before starting to transmit it over the radio link.
Let's test this radio link with a slightly different setup: iperf running on a MacBook connected (over LAN this time, so we can see statistics for this also) to CPE1 in repeater mode, CPE1 connected wirelessly to CPE2 in AP mode, which itself is connected to a TL-WDR4300 router running OpenWRT and an iperf server.
Thats what iperf running on the MacBook shows:
Following is statistics for the WLAN7 interface at CPE1. Note that the TX/RX marked in red circle shows wireless speed at a certain point in time, while the graph shows data speed, therefore data is sent with a throughput of 35 Mbps over WiFi, where the CPE achieves 75 Mbps wireless speed (50% overhead as usual for TCP/IP encapsulated in 802.11 frames over RF links):
This measuring of real throughput is much more precise than the built-in speed test, since it shows the actual data rate which can be achieved from one client device over a WiFi link to a server/router/gateway.
So I can't see a bug here.
Last edited by R1D2; 03-01-2017 at 17:16.
Same setup as above: MacBook connected to CPE510 #1, which is repeating signal from CPE510 #2, no LoS (a wall in between), position on back of CPE #2 (again, too cold outside now).
First, a WiFi survey done on the repeating CPE. Since I sit in my home-office, there are not that much APs around in the 5 GHz band, just an office AP, a smart TV and the CPE #2:
Now I connect my MacBook to the repeater and to be sure I'll get connected with the 5 GHz CPE, I take a look a status menu, tab Stations:
As you can see from the first three octets of the MAC address it is indeed an Apple device.
Now something harder to try even if it lets you turn on a "5 GHz band only" mode (more on this later): an Android tablet connecting to the CPE in repeater mode:
To get this "smart device" connected to the repeater, one must have patience. Reason is that the devices are designed to be so "intelligent" or "smart" that if there is a city wifi or a hospot with a portal page and no immediate Internet, they fall back to any known network (even if it is 2.4 GHz!) in range, although you told the device to consider only 5 GHz APs. Same with smart phones.
The developers want to make this devices intelligent, but programmers - especially from Google, Apple and (even worser) from MS - use mostly very stupid algorithms, which make your device indeed a sometimes rather dumb device. It then behaves much like a car which drives to the right while you are directing it to the left, just because "His Smartness" in its endless wisdom thinks, that on the right is something you could probably be interested in even if it is driving you into a river and you can't swim with a safety belt on in your seat. I never ever would buy a driver-less car if programmed this "smart" way.
Long story short: you have to try several times to switch WiFi off and on again after selecting "5 GHz band only" and you have to erase all known, saved WiFi networks. May be dancing 5 times around the tablet or smart phone helps also and then eventually you get connected as intended:
I really hate this "smart" shit.
Because it's so much fun playing with CPEs, I did a speed test to be able to compare with CPE210's results in the post above. On the left you see the throughput from built-in iperf on logical interface LAN to the WiFi chip on logical interface WLAN7 inside the bridge. On the right the throughput of the logical WiFi interface (WLAN7) to the connected CPE is shown:
BTW: If you do speed tests on a non-refreshing page (e.g. Network or Wireless etc.) instead of having the Status page refreshing in background, you will get more precise values:
So, no need to be pessimistic - the CPE v1 works very well with PharOS v2 even in repeater mode.
Last edited by R1D2; 03-01-2017 at 20:15.
Woa, thanks for the time and effort, really appreciate!
Alas I'm at a complete loss as to why my setup behaves as such..The only difference I picked up from the screenshots you provided is that I use WPA-PSK (AES) in all my CPEs. Could you possibly test out that too (enable security in WPA-PSK AES mode) if it's not much of a problem now that you set the bar high already and report back? The other thing is that I have both ports of my repeater occupied, i.e. port 0 goes to a router serving a local network and port 1 is used for a wired camera.
The idea was that such a setup would enable CPE#3 to get internet from CPE#1 with CPE#2 being the intermediate repeater / bridge. Having bumped-into other bandwidth-related issues I see this idea now not being rolled out afterall as other factors have also contributed towards creating two autonomous AP/Client sub-networks in the end, i.e. CPE#1a servicing CPE#2 and CPE#1b servicing CPE#3 as notably suggested by you and Victor a couple of months back.
Good news is: Yes, it also works with WPA2-AES encryption. It didn't work immediately when setting the repeater first and the AP thereafter (TX: 0 bytes), but when I did it the other way around they eventually got connected:
But now for the bad news:
I wouldn't recommend repeater mode at all. First reason: throughput theoretically will drop by 50% due to additional AirTIme required to serve two radio links. But in practice it will drop even lower:The idea was that such a setup would enable CPE#3 to get internet from CPE#1 with CPE#2 being the intermediate repeater / bridge.
Compare this with the results above (CPE210). Really a bad throughput.
Second reason for not using repeater in between a long-distance link is that if CPE #1 and CPE#3 can't see each other, you will undoubtly run into the hidden node problem. Big trouble! To avoid the HNP, TP-Link introduced MAXtream. But unfortunately MAXtream doesn't work in repeater mode.
Therefore I would recommend - if only used for the camera link and you want to use 3 devices- to set up CPE #2 as the AP and connect CPE#1 and #3 in client mode. Then you could turn on MAXtream to avoid the HNP. Of course, you will have to use routing then instead of bridging, but this should not be a problem.
If using 4 CPEs for a relaying link you are always on the safe side.
Last edited by R1D2; 03-02-2017 at 09:02.