Re: [B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS

["Jan Lühr" <ff@jluehr.de>]

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