Hello,

Am 07/01/2014 11:21 AM, schrieb elektra:

Hi –

...

...

...

During an experiment it was found, that BATADV_FRAG_MAX_FRAGMENTS=16 allows ~72 clients to be connected to one single access point.

would you mind sharing some details regarding the experiments you performed ? The reason for this question is that there is no 72 client limit we know of (unless fragmentation was disabled).

you are very likely looking in the wrong direction. The number of clients allowed to connect to an AP is configurable and 72 is already way beyond what I would consider useful in real life – if your clients are actually supposed to be able to communicate unicast traffic.

Since you are probably using OpenWRT for your tests, look at the configuration parameter maxassoc: http://wiki.openwrt.org/doc/uci/wireless

I don't know the default that OpenWRT uses if you don't set it explicitly. But there is a default limit set somewhere (take a look at hostapd.conf) and you might have discovered that by pushing it to the limit. It might as well be the limitation of your WiFi driver / hardware, though.

After a lively discussion on irc, I'd like to finalize this thread. To summarize, where we are so far:

-> batman-adv is not restricted to 72 clients. Pre-2014 versions (which have been used here), support > 200 non-clients in their tt-table.

-> Initially posted by g3ntleman on the Freifunk-KBU mailinglist, an observation (why can we handle 72 clients), became a rumor (there might be a limit in batman-adv), became a fact (we observed a limit in batman-adv) - without any support.

-> G3ntlemans setup was not meant to be in experiment in a sane setting. It was an emergency fix for a broken down conference wifi. Which - nevertheless - showed some interesting findings. I hope, that we can document this for future reference, but the relevance of the findings in general is probably rather poor.

-> The aftermath of the discovery was motivated by the idea of running an experiment at this year's FrOSCon. If you like to join us here, you're welcome :-).

-> It's still unclear, what we observed in detail and we'll probably never know for sure. The reason is simple: No measurements / logs were taken and we cannot reproduce the setting.

-> To emphasis this: It's neither evident nor even probable that any property of batman-adv is a bottleneck in this scenario.

-> The used setup was not meant to be suitable for a conference wifi or even high density wifi coverage. It suffers from obvious design flaws. G3ntlemen just remembered having his box with him, the moment the conference wifi was down. There was not a single thought spent on scaling issues here.

-> I don't know, if 72 clients on a single wifi channel is sane or not ( Ubiquity claims, that the can handle 100) - and - if pre 802.11n experiences (aka gut feelings) are applicable. However, getting a gut feeling is the idea for this year's FrOSCon. Thus: Join, if you're interested.

I'd like to excuse for all anger, frustration or hassle generated by this discussion, and, I'd like to thank marec and ordex for their helpful comments. Keep calm, carry one and thanks for your commitment to batman-adv.

Greetz, Jan