2ms window in SRS mode A5 - C5

Hello,

Are there plans to allow a 2ms window size when running service between an A5 and C5 in SRS mode?

2 Likes

Hi, I think yes, but waiting like rain in the desert :sweat_smile:

Waiting for timeline.

2 Likes

Hello.

I am still wondering about this over 6 months later it seems, with no official reply.

Thank you.

1 Like

I am not sure we will ever see anything besides 8ms. Even though we would probably use lower window sizes.

The larger window size allows for more total aggregate bandwidth then smaller window sizes, but the increased latency is something I dislike. 20-30 ms for many clients especially during heavy utilization. That said, the vast majority of people in this industry prefer the greater bandwidth over lower latency (just look at the Ubiquiti Airmax forums and you will see almost everyone is on 8ms 67/33 or 75/25) And there are very few applications that are effected by a consistent 20-30 ms. VoIP can handle it, Streaming doesn’t care, web browsing cares even less, gamers are few and far between and often don’t know better.

I think what we really want is to adjust our window portions to 67/33 or even 75/25. I think we have a lot of airtime lost being stuck at 50/50.

1 Like

Very interesting, but like always I prefer to switch the right setup on each situation. So if I have the option to choose another windows time is better than a fixed one.

While I’m not sure about the timing windows, I do know asymmetric traffic split is coming soon. I will try and get more info about additional timing windows.

Edit:

Our product guys have tested with lower TDMA windows, but found it didn’t really provide any improvements. There are no current plans to include 2 or 4ms timing windows to PTMP.

1 Like

All,
I just finished testing an A5C and a C5. The latency was much higher than I expected at stayed around 22 ms from the SM to the BS even at optimal signal level and quality. Is there something that can be done to lower this via a setting or optimization? What is the best latency than can be expected?
Thanks

If you have quiet spectrum, not very many clients and not too far to go you could go “WiFi Interop” instead of using GPS fixed timing it relies on RTS. That might give you lower timings, but those could become irregular with too many clients or high throughput.

You might be able to drop some latency with prioritization, but most of the built in Mimosa stuff in that department is focused on bandwidth.

If it is a particular client that needs really low latency, then a PTP link is the only real solution inside of the Mimosa realm. Ubiquiti will let you use various timing windows (5/8/10 I think) and they have asymmetric traffic split (66/33, 75/25 depending on the window size)

1 Like

thanks for the update, that helps.

Much as I hate to ring up old topics, there aren’t that many in this forum…
A shorter window will be more important now than before. If anyone wants to use the A5 to serve customers covered by the Connect America Fund, the FCC now demands that 95% of busy hour pings come under 100 ms., to an actual IXP, not just the AP. So if you have some B5s feeding an A5, it adds up. I can and do set B5s to 2 ms (it’s not often I need to go farther than that supports), and an A5 at 2ms would not only help on the latency, but help stay sync’d, like multiple B5s, if the two radios can use compatible timing.

So I disagree, over 5 wireless links (Client to A5 (SRS), AP to tower 1 5GHz, tower 1 to tower 2 (6 &11 GHz), tower 2 to tower 3 (11GHz), tower 3 back to tower 2 (because this AP is an extension of tower 3 and I VLANed around, not my hottest idea, but it works) then out to the internet to my closest IXP (which the government okayed, is Denver, over 40 miles away) I get:
image

Latency is the easy number to hit, even under load I don’t see pings to that AP getting above 30 ms. And I have not seen Pings from Mimosa APs to Clients going above 30 ms either. So unless you have over 40 ms of latency between you and your closest IXP (that the government is using) you will be just fine. (And that system has lots of latency that can be cut out of it by simple improvements in network design. Most of the rest of my APs have under 5 ms of latency to them even when the network is under load.)

By cutting down on your window sizes, you are decreasing the amount of total throughput that your AP can push, which IMO is the number that is most sensitive to issues. You only need 96% of your pings to be below 100 ms, where the speed testing during peak times is a much harder set of numbers to make sure you hit. (God forbid that the sensitivity of your testing system doesn’t wack out and do a bunch of tests while your customer is trying to download the latest Call of Duty)

You are totally missing my point, William. Your backhaul links are licensed FDD. That has negligible latency, just microseconds. I’m talking about B5 links, which are TDD. They have 2 to 8 mlilisecond frames, and latency on the order of 2-3 times the frame. So latency adds up QUICKLY.

Cutting down on window sizes decreases throughput a wee wee bit, but that only matters if the radio is near full load. Speed testing will probably be trivial compared to latency with multiple TDD backhaul hops. And the rules for speed testing are MUCH more tolerant. 95% of packets is a b*tch, since IP networks discard packets by design. The FCC does not understand that, does not want to understand that, does not care about that. Also, latency tests are run every minute during the busy hour, while speed tests are only run hourly. And speed tests are only to 80%, 80% of the time, vs. 100% of the target speed (101 ms. is a fail) 95% of the time.

Actually my backhauls are all only TDD. (Or TDMA-FD as Mimosa likes to call it, still time division)

The first leg is through a Ubiquiti Rocket Prism 5AC Gen2, which has a fixed 5ms window. LOL UBNT in a Mimosa network.

The next goes either through an old Dragonwave or almost as old Ligowave. Both are TDD.

Finally the B11 that I cross twice, I just use Auto though we probably will have to to to fixed framed TDD in the near future. Somewhere someone broke down the latency cost vs bandwidth cost for various window sizes, but I can’t find it right now. (I think it was on the Ubiquiti forums when they were first implementing GPS) But the longer window sizes had significantly more bandwidth available to them where as you were only loosing a few ms of latency.

Sure if you have a really long line of wireless backhauls, you are going to run into issues. That’s what is killing RISE out by me. But the PTMP access point is going to add lots more latency no matter what, it’s having to talk to dozens of customers at the same time.

Now, don’t get me wrong, I am really excited to compare notes with you. You are the first other WISP I have come across who also has to do the testing. I just greediness with you on which portion of the testing will be harder. (Unfortunately for me, the area I have to do testing on is my old area which is all UBNT equipment, if we could have gone Mimosa years ago I would not be in this situation.)