I recently changed a mixed ubnt-mikrotik link (that was working okayish) to a mikrotik ac link.
it’s going from a village to the city.
i did my best to re-allign the dishes, consider this is a NLOS link, slight visual obstruction. i think just the roof of the house in front is the only obstruction.
it’s a 6-7km link.
i tested a few frequencies and decided on a cleanest one, although antennas do not have much gain on the low end of the 5ghz band. in the mid band i was seeing -60 but i couldn’t fit 80mhz channel there, and there’s interference very near both top and bottom of the 40mhz channel and we know mikrotik don’t like co-channel interference. it was working but not as fast as here.
i tried both nv2 and plain 802.11ac and decided to use 802.11ac , it’s completely clean air and is more stable that way.
that said - why when i do test in both directions i see this shit speed?
speedtest is over 100mbit each direction, internet speedtest shows me about 95/90mbit…
First of all, this test tool is using the CPU to generate random data to send to the other router, the other router then generates random data to send back. This is not testing your link, it is testing your CPU. Use your PC to run some test like IPERF, the MIPS routers don’t have enough resources to generate data and also transfer it
And when you go over to using proper test setup (e.g. iperf running on computers, connected to wireless link endpoints) also keep in mind the following about bidirectional tests:
wifi is a TDMA, so same air time is divided between both directions. In ideal case the sum of throughputs in both directions will be always the same (the same as maximum for unidirectional test) regardless the throughput in either of directions. In reality it may be a bit lower due to Tx collisions (unless you enable RTS/CTS as hardware protection mode … which gets rid of collisions but add slight overhead due to need for AP to allow station to transmit)
when doing TCP tests, TCP feedback (a.k.a. ACKs) uses up bandwidth in the return direction. When doing bidirectional tests, the return path will be congested as well, so ACKs get delayed … making sender to throttle down Tx speed … which can be below the forward path throughput. So if one really wants to stress the link in both directions concurrently, then one has to run UDP tests and observe the receiving side stats to get actual throughput numbers, sender doesn’t have a clue about what get through. (additionally, TCP tests throughput doesn’t account for throughput by ACKs, so the bidirectional test results will be a tad lower than what link actually does during test)
i don’t have computer on the remote point, it’s just a ptp relay station. there’s an omnitik poe for powering ap devices and then a total of 3 ptp links.
from what i can see unidirectional works quite well so in real life it should also work well. i will probably see saturation in download, but i don’t think there’ll be much uplink.
ps didn’t know this thing about ack packets etc. i never bothered to test in both ways , this is the first time i think, so this bad results shocked me frankly. but i’d say this is working. if unidirectional goes 100-140mbit, then even with 10-15mbit uplink (if ever) the downlink should still go above 50. it’s plenty enough.
It might … the thing is that it’s not only raw speed, it’s timing which plays huge role in bidirectional communication (any TCP connection is bidirectional). And the fun is the part where different TCP implementations (of end devices, i.e. phones, tablets, laptops, and servers) are affected by timing “issues” differently, so some server/client pair can then behave completely differently than another pair of server/client …
In my previous post I wrongly wrote that WiFi is TDD … it’s TDMA (I’ve corrected the text … but with only two devices contributing to “network” it essentially becomes TDD). But there are some (nonstandard, proprietary) implementations of TDD for PtP and PtMP links … MT has nstreme (I think nv2 is not) where it is (in principle) possible to set the share between the directions … which then makes speeds in one direction less susceptible to traffic in other direction (as far as Tx time for each device in such wireless network goes). Straight 802.11 doesn’t have it, one station can, in theory, take over all the available air time and the rest (including receiving station) have no possibility to transmit their (queued) data.
