public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Christof Schulze <christof.schulze@gmx.net>
To: elektra <onelektra@gmx.net>
Cc: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] Fwd: Re:  increasing BATADV_FRAG_MAX_FRAGMENTS
Date: Wed, 02 Jul 2014 19:25:59 +0200	[thread overview]
Message-ID: <2115088.IOMlxmsL1n@lappi> (raw)
In-Reply-To: <20140701112142.3c8ab7cd16f81b51da706026@gmx.net>

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

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.
Thank you for your response.

maybe it is indeed a little far-fetched to point at batman at first.
On the other hand - the investigation has to start somewhere.

From your feedback and from feedback on IRC I gathered the following
list of possible issues and things to look at:
* there might be an issue with not enough multicast-traffic being
  allowed - hypothesis: The client could associate with the AP but
  no IP was received. 
* the bandwidth of the air (airtime) might be saturated. 
* There might be a driver issue

If it is known that no more than 70 clients per device is sensible,
then we have to consider actually setting some limits and using
maxassoc.

Christof


-- 
()  ascii ribbon campaign - against html e-mail
/\  against proprietary attachments

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

      parent reply	other threads:[~2014-07-02 17:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30 22:07 [B.A.T.M.A.N.] Fwd: Re: increasing BATADV_FRAG_MAX_FRAGMENTS Christof Schulze
2014-07-01  9:21 ` elektra
2014-07-01 12:25   ` Jan Lühr
2014-07-02 17:25   ` Christof Schulze [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2115088.IOMlxmsL1n@lappi \
    --to=christof.schulze@gmx.net \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=onelektra@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox