AirMax jitter

[Flo]

:ubnt_banana: Hi Ubiquiti Dev-Team,

do you see a change to decrease the high jitter which occurs at least on large AirMax distance links (~14 miles)?
i.e. test pings via 14.5 miles P2P dual polarity RocketM5 AirMax WDS-bridge:

~ # ping -s 1414 10.20.30.40
[...]
1422 bytes from 10.20.30.40: icmp_seq=900 ttl=64 time=19.467 ms
1422 bytes from 10.20.30.40: icmp_seq=901 ttl=64 time=14.430 ms
1422 bytes from 10.20.30.40: icmp_seq=902 ttl=64 time=6.418 ms
1422 bytes from 10.20.30.40: icmp_seq=903 ttl=64 time=3.029 ms
1422 bytes from 10.20.30.40: icmp_seq=904 ttl=64 time=18.533 ms
1422 bytes from 10.20.30.40: icmp_seq=905 ttl=64 time=12.499 ms
1422 bytes from 10.20.30.40: icmp_seq=906 ttl=64 time=3.869 ms
1422 bytes from 10.20.30.40: icmp_seq=907 ttl=64 time=21.568 ms
1422 bytes from 10.20.30.40: icmp_seq=908 ttl=64 time=15.700 ms
1422 bytes from 10.20.30.40: icmp_seq=909 ttl=64 time=4.195 ms
1422 bytes from 10.20.30.40: icmp_seq=910 ttl=64 time=19.022 ms
1422 bytes from 10.20.30.40: icmp_seq=911 ttl=64 time=4.915 ms
1422 bytes from 10.20.30.40: icmp_seq=912 ttl=64 time=19.433 ms
1422 bytes from 10.20.30.40: icmp_seq=913 ttl=64 time=20.321 ms
1422 bytes from 10.20.30.40: icmp_seq=914 ttl=64 time=12.740 ms
1422 bytes from 10.20.30.40: icmp_seq=915 ttl=64 time=20.733 ms
1422 bytes from 10.20.30.40: icmp_seq=916 ttl=64 time=14.738 ms
--- [...] ping statistics ---
917 packets transmitted, 917 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 2.850/11.975/29.331/5.949 ms

:icon_arrow: I've also noticed that the jitter does not change in high and low load situations; so AirMax enabled seems to work very stable so far on firmware v5.0.2 :icon_smile:

:icon_question: Is it possible to enable QoS based on TOS or DiffServ?

Cheers,
-Florian

[drwho17]

High jitter? That looks pretty wicked good to me.

[Flo]

High jitter? That looks pretty wicked good to me.

Well, standard TCP/IP connections don't like it without tcp_moderate_rcvbuf enabled (If set (1) TCP automatically adjusts the size of the socket receive window based on the amount of space used in the receive queue.);
Interactive (VoIP, gameing, etc.) applications also don't like jitter.

At least if you're bridging with Ubiquiti AirMax over a few points you'll get in trouble with this jitter behaviour: 4 bridge-links -> jitter between 5-120ms!

without AirMax enabled you have 1-3ms with low load and 15 or more ms on medium to high load situations; but without such a jitter.

I guess this interacts with http://www.ubnt.com/forum/showthread.php?t=14591 ...

-Florian

[UBNT-Mike.Ford]

Hey guys,

We are activly investigating this.

Thanks,

[konceptio]

Well normally any pooling mechanism will add extra latency. The key is to make this latency stable. On proxim tsunami or motorola you see similar behavior but atleast it does not jump from 10ms to 100 ms unless some crazy retransmission is going on.

if you do Point to Point you do not need AirMax unless UBNT will make an AirMax option with out pooling like proxim tsunami has and take advantage of TDMA only.

[Flo]

Hey guys,

We are activly investigating this.

Thanks,

Thanks Mike :icon_cool:

[Flo]

[...]
if you do Point to Point you do not need AirMax unless UBNT will make an AirMax option with out pooling like proxim tsunami has and take advantage of TDMA only.

On our two ~16 miles test links the performance and stability improves a lot on enabling AirMax in a full duplex environment. I guess that's because TDMA avoids collisions and the backoff waiting in case of occuring collisions.

:ubnt_banana: pure P2P-bridging support with TDMA only would be perfect for these scenarios :icon_razz:
Maybe it's possible to implement this feature within the next firmware without large additional effords.

Cheers,
-Flo

[Flo]

Hi Mike,

Hey guys,

We are activly investigating this.


:icon_arrow: do you have news to this case regarding the upcoming firmware V5.1 (beta)?

-Florian

[UBNT-Mike.Ford]

Hi Mike,



:icon_arrow: do you have news to this case regarding the upcoming firmware V5.1 (beta)?

-Florian


hello,

Should be much better with V5.1

Thanks,

[broken]

Testes with Nano M5 with latest 5.1 Beta with AirMAX - with idle link ping is around 2-10ms. But sometimes its going up to 200ms with 10-12 seconds interval.

[UBNT-Mike.Ford]

Testes with Nano M5 with latest 5.1 Beta with AirMAX - with idle link ping is around 2-10ms. But sometimes its going up to 200ms with 10-12 seconds interval.

Is this with or without AutoACK?

Thanks,

Mike

[HighlandsWireless]

On our two ~16 miles test links the performance and stability improves a lot on enabling AirMax in a full duplex environment. I guess that's because TDMA avoids collisions and the backoff waiting in case of occuring collisions.

:ubnt_banana: pure P2P-bridging support with TDMA only would be perfect for these scenarios :icon_razz:
Maybe it's possible to implement this feature within the next firmware without large additional effords.

Cheers,
-Flo


Scenario;

I use licensed microwave for my main backhaul routes and want to use the RocketM5 for the distribution from each of these mountain tops to a few AP sites in each valley which consist of about 4 sectored AP’s at each site. Each site will aggregate up to the RocketM5 back to the mountain top. So the RocketM5's will be used to feed other AP’s and each RocketM5 will only need 15 to 35Mb of bandwidth each at an average range of 6 to 20 miles. That is why reliability and Latency are the highest priorities.

Two questions;

(1) Under the current firmware (5.0.2) what settings would be the best for the following point to point priorities?
(a) Highest reliability [highest priority by far]
(b) Latency [much more important than throughput]
(c) Throughput


Can Ubiquiti / will Ubiquiti?? Or feature request!

(2) In your future firmware to have the ability to set the speed of each direction would be real handy. In the above scenario to be able to set the down-stream rate at about 35Mb and the up-stream at about 15Mb would work well for this situation and with those low codex rates the reliability should be very high, and latency should be very low, as the RocketM5 would not be looking at trying different higher codex rates that are not needed as well as the overhead to ‘shift speeds’ which eats time or latency. This in turn keeps the latency low by keeping the unit ONLY doing a set job with no "looking" around or thinking. Ubiquiti has put a good amount of intelligents into this product and it automatically does a good amount of work, but some of us know exactly what we need and would like to be able to disable that intelligents and just set the units to do a set job. Also keeping it TDMA and allowing us to 'book' the speeds and rates would make this a much more and very versatile product. The one automatic part I would like to see in this scenario is automatic power control so that self interference would be kept to a minimum.

[nath12]

I am very curious about this situation, I have experienced similar issues with high ping, sometimes as low as 1.5 ms but sometimes as high as 40 to 50 it reaks havok with my UMA from T-Mobile. My setup is 12km partial/nlos from a house rooftop to a water tower No Airmax, fixed ack, aggregation set to default, and then relayed through another Bullet PtmP w/Airmax and aggregation to default auto ack(which seems to work fairly well). I am an amateur when it comes to this stuff, so I feel like just getting everything fairly stable has been a huge accomplishment. Your products seem to work much better than some of the other devices I have used and your UI is much much much better. Thanks

[UBNT-sriram]

Hi Guys,

Can you upgrade to 5.1-RC3 and let me know.

Sriram

[nath12]

I have been using 5.1-RC3. I'm wondering if there may be interference. I'm using Channel 13, and didn't see anything significant using the UBNT 2.4 Ghz spectrum analyzer, and both radios almost always show a -96 db noise floor.

[aaron]

collect and graph snmp data from the ubnt product the tx/rx data rates, tx/rx signal, sig to noise, tx/rx ccq%

also run pings to a few or all radios at a default 32byte packet and also 1470byte or 1500byte packet collect and graph these.

this might help identify if a particular radio is causing the problem, or at least help find where the jitter is coming from.

a little stats can go a long way.