Community discussions

MUM Europe 2020
 
User avatar
BrianHiggins
Long time Member
Long time Member
Topic Author
Posts: 598
Joined: Mon Jan 16, 2006 6:07 am
Location: Norwalk, CT
Contact:

Max Station Count, NStream, and better uptimes

Fri Oct 31, 2008 4:18 pm

I've been testing out the net NStream polling test package on a few APs (http://forum.mikrotik.com/viewtopic.php?f=7&t=27302) and it has got me thinking about the polling mechanisim and how it works...

So I did a quick test on a heavily loaded 5.8 sector running 3.10 and about 40 CPEs connected (NStream+Polling), average latency was about 80ms to the client, but after changing the Max Station Count to 60 (I took a wild guess and picked the number of CPE's connected * 1.5), the average latency dropped down to 40ms! Changing the Max Station Count back to the default of 2007 increased average latency back up to 80ms, and then back to 60 and again back to 40ms ping averages.

Another test on an AP with the new test package shows less dramatic, but still improved resultes on latency, averages were roughly the same (from 6ms to 5ms), but jitter was noticably less and max ping times were about half (from 61ms to 32ms).

Had a customer call in yesterday with a SR9 CPE yesterday that couldn't maintain a radio link to the tower for more then 2-3 seconds, this AP was running the new NStream Test package. Changed the max station count from the default 2007 down to 1.5 times the number of CPEs connected, and his CPE has not disconnected yet in 18 hours.

It seems the support documentation for this setting needs to be revised along with alot of testing to find out just what this setting really effects, and some input from the programmers to find out what a good value for this should be (I'm sure my 1.5 times the number of connected CPEs can be improved on)
max-station-count (integer: 1..2007; default: 2007) - maximal number of clients allowed to connect to AP. Real life experiments (from our customers) show that 100 clients can work with one AP, using traffic shaping
Has anyone else noticed this about the Max Station Count? In the past we have always just left it default thinking it was a pretty much useless option.

What everyone else have yours set to? Do you see similar improvments to mine when changing it?
 
Mplsguy
MikroTik Support
MikroTik Support
Posts: 226
Joined: Fri Jun 06, 2008 5:06 pm

Re: Max Station Count, NStream, and better uptimes

Fri Oct 31, 2008 6:29 pm

ForePoint, max-station-count affects only amount of clients that are allowed to register, nothing more. So probably differences you have observed are caused by something else - number of clients registered at the moment you "tested" latency or what they were doing at that time as it all can affect latency.
 
User avatar
BrianHiggins
Long time Member
Long time Member
Topic Author
Posts: 598
Joined: Mon Jan 16, 2006 6:07 am
Location: Norwalk, CT
Contact:

Re: Max Station Count, NStream, and better uptimes

Fri Oct 31, 2008 9:47 pm

I have trouble beleiving that is all it affects (at least when NStream + Polling is enabled).

I've tested at least 6 APs now and seen latency decreases on every one of them, and now 3 seperate cases on different APs where radio links that were not staying stable, are stable after changing that value (and NOTHING else).
 
cmit
Forum Guru
Forum Guru
Posts: 1552
Joined: Fri May 28, 2004 12:49 pm
Location: Germany

Re: Max Station Count, NStream, and better uptimes

Mon Nov 03, 2008 1:09 pm

Well, that it ONLY defines how many clients are allowed to connect is what the docs say.
The experiences here point to something else, where the MikroTik dev team could shed some light.
I would say it's not that unrealistic to suspects it's doing more here. As NStreme in PtMP is something like a time-slot algorithm, it might well be that it "reserves" timeslots for the maximum number of possibly connected clients (which you can configure) or something like that.
Best regards,
Christian Meis
 
Muqatil
Trainer
Trainer
Posts: 574
Joined: Mon Mar 03, 2008 1:03 pm
Location: London - UK
Contact:

Re: Max Station Count, NStream, and better uptimes

Mon Nov 03, 2008 1:18 pm

I was testing wireless-test aswell but i gave up until the package is more stable (I had some clients downtime)
By the way... the max-station-count locks the number of stations on each radio..
The question is: The client when it got refused by a radio, does it try to connect to another radio or does it retry to connect on the same?
Renato Bernardi

skype: medtech5
 
Muqatil
Trainer
Trainer
Posts: 574
Joined: Mon Mar 03, 2008 1:03 pm
Location: London - UK
Contact:

Re: Max Station Count, NStream, and better uptimes

Mon Nov 03, 2008 4:22 pm

Edit: They connect to another radio :lol:
Renato Bernardi

skype: medtech5
 
User avatar
BrianHiggins
Long time Member
Long time Member
Topic Author
Posts: 598
Joined: Mon Jan 16, 2006 6:07 am
Location: Norwalk, CT
Contact:

Re: Max Station Count, NStream, and better uptimes

Mon Nov 03, 2008 6:43 pm

I would say it's not that unrealistic to suspects it's doing more here. As NStreme in PtMP is something like a time-slot algorithm, it might well be that it "reserves" timeslots for the maximum number of possibly connected clients (which you can configure) or something like that.

that is exactly what I have been thinking. I posted essentially that question to the MT guys in the nstream test thread about this, but haven't gotten a response yet.
 
Mplsguy
MikroTik Support
MikroTik Support
Posts: 226
Joined: Fri Jun 06, 2008 5:06 pm

Re: Max Station Count, NStream, and better uptimes

Wed Nov 05, 2008 4:57 pm

ForePoint, like I said - max-station-count really only limits number of clients that can register. If in your setup this limit is not reached, there definitely is something else that causes this. You can test it by simply disabling/enabling wireless interface - this would effectively be the same as changing max-station-count.

If limit is reached (and some client(s) are not allowed to connect), what happens next solely depends on client software - they can retry to connect a few times, search for another suitable AP, retry periodically, etc.
 
User avatar
BrianHiggins
Long time Member
Long time Member
Topic Author
Posts: 598
Joined: Mon Jan 16, 2006 6:07 am
Location: Norwalk, CT
Contact:

Re: Max Station Count, NStream, and better uptimes

Thu Nov 06, 2008 9:57 pm

ForePoint, like I said - max-station-count really only limits number of clients that can register. If in your setup this limit is not reached, there definitely is something else that causes this. You can test it by simply disabling/enabling wireless interface - this would effectively be the same as changing max-station-count.

If limit is reached (and some client(s) are not allowed to connect), what happens next solely depends on client software - they can retry to connect a few times, search for another suitable AP, retry periodically, etc.
Mplsguy: I don't want to be negative here or make this personal, but did you not read the posts you were replying to?

If I decrease the max station count, and ping times decrease, and then I return it to default a few minutes later, and ping times increase, and then again I decrease the max station count, and ping times again decrease, and the only thing I've changed out of the 4 instances I've been testing was the max station count (and having never reached the max as it's set to 1.5 times the number of clients on the AP), then pretty clearly something related to the max station count is affecting more than just the number of radio's allowed to connect.

The point CMIT and myself were agreeing upon is that the documentation may not be telling the whole story here and that something with the NStream Polling mechanism appears to be affected by this setting. My goal with this topic was to have others perform their own tests to see if they were seeing the same results I was seeing and if so, bring the issue up to the guys at MT and make them explain what we were seeing, in the interest of better understanding the technology so that we can build better performing networks, to provide better quality service to our customers, which I assume is a common goal of most of the people on this forum.

Therefore PLEASE, unless you have some inside knowledge on the inner workings of the polling algorithm and exactly how it works and would like to share it, Please stop repeatedly quoting the documentation (which hasn't even been updated since January 22, 2008) that I already referenced in my first post on the subject (in hopes that it would point out to anyone reading that I have already done that research and still feel there is a topic worthy of discussion after said research, to prevent exactly this from happening).

Your negative feedback on this topic is potentially, and probably discouraging others from doing their own testing to determine if this setting change could be of benefit to them and help solve some of the issues we have all experienced in the past. If you want to contribute on this forum, Please do so in a helpful and constructive way such as to perform the tests yourself assuming you have a PtMP NStream environment to test on, and then respond to the forum with your results, not simply quote the documentation, which it's accuracy is in question to begin with.
 
Mplsguy
MikroTik Support
MikroTik Support
Posts: 226
Joined: Fri Jun 06, 2008 5:06 pm

Re: Max Station Count, NStream, and better uptimes

Fri Nov 07, 2008 11:25 am

ForePoint, I did read the posts. And yes - your guess is right - I do have "inside knowledge on the inner workings" and my comments are based exactly on that, unluckily I do not think "exactly how it works" is going to be disclosed. I am sorry if my comments make you feel your testing efforts are undervalued - they are not. Whole purpose of telling what max-station-count really does (and yes - in this case documentation is right) is to protect you from making wrong conclusions based on results that are actually caused by something else.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24337
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: Max Station Count, NStream, and better uptimes

Fri Nov 07, 2008 11:28 am

Forepoint, If I were you, I would trust the guy
No answer to your question? How to write posts
 
User avatar
BrianHiggins
Long time Member
Long time Member
Topic Author
Posts: 598
Joined: Mon Jan 16, 2006 6:07 am
Location: Norwalk, CT
Contact:

Re: Max Station Count, NStream, and better uptimes

Fri Nov 07, 2008 5:19 pm

I do have "inside knowledge on the inner workings" and my comments are based exactly on that, unluckily I do not think "exactly how it works" is going to be disclosed.
Why would this not be disclosed? It is to everyone's benifit to better understand the systems we work with every day. If you have this type of information, I don't understand why you (for that matter MT themseves) don't just put the facts out to answer the question from the begining, instead of this back and forth thing of you saying essentially "trust me, your repeatedly duplicated test results across numerous APs, are false" over and over.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24337
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: Max Station Count, NStream, and better uptimes

Mon Nov 10, 2008 2:52 pm

This part of RouterOS is not open source, so how it works is protected information. basic principle has been explained, that should be enough to make it work
No answer to your question? How to write posts
 
macpacheco
just joined
Posts: 10
Joined: Sun May 31, 2015 2:19 am

Re: Max Station Count, NStream, and better uptimes

Sat Aug 05, 2017 11:26 pm

When you make changes to the AP configuration, it resets, dropping all clients.
Those must then reconnect. Not all clients reconnect quickly.
Perhaps you should change this parameter and wait several hours before doing your ping test instead of trying to concoct paranoid theories as to why there's a difference in latency.
Also the interval until wireless clients reconnects might be long enough that all high throughput transfers have now died or slowed a lot or worse, the customer IP changed and transfers must be re-established.
You need to compare apples to apples.
Study more about how wireless, ethernet and the internet in general works.
People here seek magic solutions whose cures require knowledge. Knowledge that you're not going to get in a month or a year.
Good luck !
 
empy
newbie
Posts: 26
Joined: Sat Nov 19, 2016 6:12 pm

Re: Max Station Count, NStream, and better uptimes

Fri Dec 08, 2017 12:56 pm

Does anybody know how the Client are rejected if Max Sation Count is reached?
Maybe a response to the authentication attempt with Status Code 17? AP Busy / Association denied because AP unable to handle additional associated stations

Is that how it works?

Who is online

Users browsing this forum: No registered users and 27 guests