On Sunday 07 March 2010 19:31:37 Felix Fietkau wrote: > On 2010-03-07 6:59 PM, Christian Lamparter wrote: > > On Sunday 07 March 2010 17:39:47 Felix Fietkau wrote: > >> here is an updated version of my minstrel_ht code. Since the last > >> version, I've added the following improvements: > >> > >> - Use accurate A-MPDU statistics from tx feedback > >> - Rewrite the sampling algorithm to optimize for good A-MPDU lengths > >> and faster throughput recovery > >> - Implement .rate_update to handle changes in HT capabilities or > >> channel bandwidth > >> - Remove the private tx flags hack > >> > >> With the new version, performance has improved visibly for HT40 in all > >> of my tests. I think it's getting closer to being ready for inclusion. > >> --- > > Just released carl9170 1.0.3.1 which now uses minstrel_ht. > > > > I found a few things, not sure if they are bugs in the driver > > or minstrel_ht code. (Patch attached, but added the comments > > as a response to the code) > Thanks. How well does it perform in your tests compared to the old rc? Hard to see any big difference under real life conditions. But there are some "gains" with _synthetic_ benchmarks. most notably: uni-directional UDP traffic now suffers much less from package loss (old rc: ~ 3 - 7%, compared to minstrel: 0.0001% - 0.01%). The throughput is not affected, It levels out at around ~130Mbits/s in both tests. > > on startup, carl9170 complains about non-aggregated > > (CTL_AMPDU not set) MCS frames. I had to add an > > alternative path for these _early_ frames. They are > > now send with the "lowest" legacy rate and aren't > > rejected by the driver/HW. > Why does it complain - is that a driver thing or does the hardware > really refuse it? I didn't see anything in the standard that mandates > the use of A-MPDU with MCS rates. WARN_ON in the driver. But yeah, on a second look: It's just some old code from my own minstrel_ht (back in October 2009) On a third look: The original vendor driver logic almost _forces_ the A-MPDU-bit upon HT frames. I can't tell for sure, if the "other" mode actually works or just served as a testbed for development?! So let's try: carl9170 1.0.3.2 Regards, Chr -- 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
