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?

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.

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).

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.

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?

Edit: They connect to another radio

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.

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.

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.

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.

Forepoint, If I were you, I would trust the guy

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.

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

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 !

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?