Thread (6 messages) 6 messages, 2 authors, 2011-08-29

Re: [RFC 0/3] enable HT in a mesh

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2011-08-29 13:54:57

On Wed, 2011-08-24 at 12:02 -0700, Thomas Pedersen wrote:
Hi I'm adding HT support for mesh.

This patchset is pretty basic, and relies on Alexander Simon's HT IE helper
funtions.
Ok. I'm pretty happy with those, but haven't seen the latest version of
the IBSS parts.
No channel type negotiation takes place, and the HT info IE from the
peer is not even read.
That seems odd.
In practice, nodes with mismatched channel types seem to communicate fine,
although throughput is affected (TX from HT40 -> HT20 is the worst case).
That would highly depend on rate control? Or do we do some HT
capability/operation IE stuff and figure this out? Still seems a little
strange.
We measured these data rates in our (widely uncontrolled) office environment
using the ath9k_htc driver:

        A\B           NO HT             HT20                  HT40+           
       NO HT        r: 54Mb/s         r: MCS 13             r: MCS 13         
                    D: 20Mb/s         D: 16Mb/s             D: 16Mb/s         
       HT20         r: 54Mb/s         r: MCS 13             r: MCS 13         
                   D: 22.5Mb/s       D: 18.5Mb/s            D: 15Mb/s         
       HT40+        r: 54Mb/s         r: MCS 0          r: MCS 12 @ 40Mhz     
                    D: 22Mb/s        D: 5.1Mb/s             D: 20Mb/s  

	r: rate reported by minstrel.
	D: TX throughput (A -> B using 'iperf -c <B> -u -b400M')

Is it odd that even HT40+ -> HT40+ is not any better than the non-HT case? Are
we doing something wrong? Are you surprised that mismatched channel types work
at all?
Not surprised, but won't be efficient, especially when some device uses
a dumber rate control than minstrel :)
So currently, our channel type is always just whatever the user configured
through iw. The path selection algorithm should be able to compensate by
detecting faster links and adjusting the respective mpaths accordingly.

If this is completely wrong, I would appreciate any suggestions on the right
way to handle mesh peers with different channel types.
I have no idea. The channel type stuff seems a little fishy though.

johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help