Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux