Issue 283960043: Correct most comments and bugs in MinstrelHT patchset from issue 254900043 (Closed)
|
Created:
9 years, 4 months ago by Matías Richart Modified:
9 years ago Reviewers:
S. Deronne CC:
ns-3-reviews_googlegroups.com Visibility:
Public. |
DescriptionIn this new patch set I try to deal with comments from issue 254900043 and also correct some bugs of previous patch.
It follows minstrel_ht Linux implementation, as accurate as possible.
The most important decisions are:
- Use the idea of groups. Rates are arranged in groups, considering the streams used, if it uses short guard interval and the channel width.
- There is a vector of all groups supported by the phy layer of the transmitter, for each group it is maintained the capabilities and the estimated duration of its rates.
- Each station maintains a table of groups statistics. For each group, a flag indicates if the group is supported by the station. Different stations communicating with an AP can have different capabilities.
- Adaptation of mcs, sgi, streams and channel width is made.
- Stats and rates are updated per A-MPDU when receiving AmpduTxStatus
- When HT and VHT are not supported, it uses legacy minstrel (minstrel-wifi-manager) for rate control.
- Differently from legacy minstrel, sampling is not done based on "lookaround ratio", but assuring all rates are sampled at least once each interval.
Some considerations:
- Assume patches for bugs 2316, 2317, 2319, 2320 and 2321
- RTS is sent in non-HT PPDU with a NonHtReferenceRate following the standard.
- When HT or VHT is supported, only uses HT or VHT rates.
- Currently, NS3 does not retransmit an entire A-MPDU when BACK is missing but retransmits each MPDU until MPDUs lifetime expires (or a BACK is received).
Then, we emulate MRR-chain only until the retry limit maintained at minstrel-ht is reached. Then a new rate will be selected.
- Currently, NS3 does not support disabling aggregation for particular frames, then sample rates are used on an entire A-MPDU (differently from minstrel_ht design)
Patch Set 1 #
Total comments: 27
Patch Set 2 : #
Total comments: 11
Patch Set 3 : #Patch Set 4 : #Patch Set 5 : Improve sampling, mostly in legacy minstrel #Patch Set 6 : Correct logical mistake in time comparison #Patch Set 7 : Improve max probability sorting in legacy Minstrel. #MessagesTotal messages: 10
Some first comments and interrogations already. I still need to test it and have a closer look at how it is implemented (if time). Do you believe this can be "easily" extended to support VHT as well? https://codereview.appspot.com/283960043/diff/1/examples/wireless/rate-adapta... File examples/wireless/rate-adaptation-distance.cc (right): https://codereview.appspot.com/283960043/diff/1/examples/wireless/rate-adapta... examples/wireless/rate-adaptation-distance.cc:193: wifiPhy.Set("ChannelWidth", UintegerValue(chWidth)); The channel width is overwritten afterwards by the default standard value, please use Config::Set to overwrite the default value provided by the standard. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... File src/wifi/model/minstrel-ht-wifi-manager.cc (right): https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:249: txvector.SetTxPowerLevel (0); Why is this harcoded? https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:253: return phy->CalculateTxDuration (m_frameLength, txvector, WIFI_PREAMBLE_HT_MF, phy->GetFrequency (), NORMAL_MPDU,0); Why is the preamble type hardcoded? https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:287: station->m_nextStatsUpdate = Simulator::Now (); // + m_updateStats; Should m_updateStats be added? https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:385: * FIXME In MinstrelHT Lowest baserate is not used Why? Cannot this be "easily" fixed? https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:440: /* Acording to linux code, it seems that the lowest base rate is not used in MinstrelHT. */ Do they provide an explanation to that choice? https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:573: station->m_retry = station->m_shortRetry + station->m_longRetry; //FIXME retry is never used?? Why was this defined? It seems indeed never used. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:588: { Is there a check somewhere that the station does support HT? https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:626: //FIXME Check which is the right thing to do here. View Section 9.7.6 of 802.11-2012 standard. I think the current implementation only supports RTS sent using non-HT, so I am not convinced this is ok. Once we support more features, this might get more complex. To be checked anyhow! https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:708: [station->m_mcsTable[station->m_sampleGroup].m_col]; Not easily readable... https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:1200: for (uint32_t i = 0; i < 8; i++) Why 8??? https://codereview.appspot.com/283960043/diff/1/src/wifi/wscript File src/wifi/wscript (right): https://codereview.appspot.com/283960043/diff/1/src/wifi/wscript#newcode75 src/wifi/wscript:75: 'model/minstrel-ht-wifi-manager.cc', indentation problem. https://codereview.appspot.com/283960043/diff/1/src/wifi/wscript#newcode167 src/wifi/wscript:167: 'model/minstrel-ht-wifi-manager.h', same comment.
Sign in to reply to this message.
Hi Sebastien. I try to answer all the questions and I corrected the code where needed. I upload a new patch with the corrections. Regarding the question of VHT, I think it is simple to extend. We will need to change the number of MCS (and then groups) supported depending it is HT or VHT. The configuration of the channel is a problem. The ConfigureStandard function in YansWifiPhy set the default value and overrides the value when creating the object. This is a problem because when the manager is created and configured it use the value of the channel in wifiPhy for configuration. So, I delayed the check of the phy capabilities to rateinit. Also, I'm thinking this check should be done before each rate update to consider capabilities changes during the execution. What do you think? https://codereview.appspot.com/283960043/diff/1/examples/wireless/rate-adapta... File examples/wireless/rate-adaptation-distance.cc (right): https://codereview.appspot.com/283960043/diff/1/examples/wireless/rate-adapta... examples/wireless/rate-adaptation-distance.cc:193: wifiPhy.Set("ChannelWidth", UintegerValue(chWidth)); Done. This change makes that the channel is set after the Remote Station Manager is created and then the manager use the default value. I make changes to to minstrel to adapt to this situation. On 2016/01/08 21:12:57, S. Deronne wrote: > The channel width is overwritten afterwards by the default standard value, > please use Config::Set to overwrite the default value provided by the standard. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... File src/wifi/model/minstrel-ht-wifi-manager.cc (right): https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:249: txvector.SetTxPowerLevel (0); On 2016/01/08 21:12:57, S. Deronne wrote: > Why is this harcoded? Power is not used in tx time calculation, so I take it out and let the default from the constructor. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:253: return phy->CalculateTxDuration (m_frameLength, txvector, WIFI_PREAMBLE_HT_MF, phy->GetFrequency (), NORMAL_MPDU,0); On 2016/01/08 21:12:57, S. Deronne wrote: > Why is the preamble type hardcoded? Because I understand from a comment in Gahda's patch that it was not necessary to consider GF preamble. However, if we support VHT, this will need to change to support VHT preambles. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:287: station->m_nextStatsUpdate = Simulator::Now (); // + m_updateStats; On 2016/01/08 21:12:57, S. Deronne wrote: > Should m_updateStats be added? I remove it so as to call updateStats immediately and set coherent initial values to the rates. I take out the comment. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:385: * FIXME In MinstrelHT Lowest baserate is not used On 2016/01/08 21:12:57, S. Deronne wrote: > Why? Cannot this be "easily" fixed? For me it was not so clear which would be the "lowest base rate". The lowest rate of which group? The lowest of all groups or of the current group? So I looked what is done in linux and found that. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:440: /* Acording to linux code, it seems that the lowest base rate is not used in MinstrelHT. */ On 2016/01/08 21:12:57, S. Deronne wrote: > Do they provide an explanation to that choice? I look around and found this answer to a patch suggesting adding the lowest rate http://marc.info/?l=linux-wireless&m=144602778611966&w=2 https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:573: station->m_retry = station->m_shortRetry + station->m_longRetry; //FIXME retry is never used?? On 2016/01/08 21:12:57, S. Deronne wrote: > Why was this defined? It seems indeed never used. I don't know, it is defined in original minstrel code and never used. I remove it. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:588: { On 2016/01/08 21:12:57, S. Deronne wrote: > Is there a check somewhere that the station does support HT? No, but I can easily add it. I think the best place is CheckInit. The problem is what to do if HT is not supported. Currently only one manager can be configured in MacLow, so perhaps the best solution is to merge Minstrel and MinstrelHT in one manager. What do you think? https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:626: //FIXME Check which is the right thing to do here. View Section 9.7.6 of 802.11-2012 standard. On 2016/01/08 21:12:57, S. Deronne wrote: > I think the current implementation only supports RTS sent using non-HT, so I am > not convinced this is ok. > Once we support more features, this might get more complex. > To be checked anyhow! I tested it sending RTSs and it works, although there are some comments in the code that HT is not supported yet. So, I change it and use non-HT for RTS. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:708: [station->m_mcsTable[station->m_sampleGroup].m_col]; On 2016/01/08 21:12:57, S. Deronne wrote: > Not easily readable... Improved. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:1200: for (uint32_t i = 0; i < 8; i++) On 2016/01/08 21:12:57, S. Deronne wrote: > Why 8??? Corrected. https://codereview.appspot.com/283960043/diff/1/src/wifi/wscript File src/wifi/wscript (right): https://codereview.appspot.com/283960043/diff/1/src/wifi/wscript#newcode75 src/wifi/wscript:75: 'model/minstrel-ht-wifi-manager.cc', On 2016/01/08 21:12:57, S. Deronne wrote: > indentation problem. Corrected. https://codereview.appspot.com/283960043/diff/1/src/wifi/wscript#newcode167 src/wifi/wscript:167: 'model/minstrel-ht-wifi-manager.h', On 2016/01/08 21:12:57, S. Deronne wrote: > same comment. Corrected.
Sign in to reply to this message.
Matias, It looks already better, thanks for having handle this so quickly. I have mainly two remarks: -> I think we should go for a merged Minstrel, so that legacy Minstrel can be used in case HT is not supported. -> channel width and GI seems fixed, so I only see one group being used. https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... File src/wifi/model/minstrel-ht-wifi-manager.cc (right): https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... src/wifi/model/minstrel-ht-wifi-manager.cc:588: { This was the initial thought of Tom (I saw that in his comments from Ghada's proposal), so I suggest to merge those two managers. https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... File src/wifi/model/minstrel-ht-wifi-manager.cc (right): https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.cc:20: * Ghada Badawy <gbadawy@gmail.com> Feel free to add you as author, so that interested people can easily contact you in the future. https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.cc:27: * 2) 40Mhz can't fall back to 20MHz I testing with channel width 40 MHz and it seems indeed not testing rate of 20 MHz, so it stays fixed to 40 MHz channel. I can live with that for the moment since our error models do not model (yet) channel aggregation, so basically you will get same error rate at 20 MHz and at 40 MHz, so it would make sense to keep a fixed channel. But if once we do support dynamic channel width selection, I wonder if this will still be ok... And what about SGI? I see the same thing happening (fixed GI): previous comments apply also to GI selection. https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.cc:354: * FIXME In MinstrelHT Lowest baserate is not used I suggest to indicate a reference to the Linux implementation in order to explain this choice. https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.cc:592: //Using the lowest non-HT rate. I suggest to explain why non-HT is used for RTS frames (maybe point to a reference in the standard and tell that we do not currently support cases where RTS is transmitted using HT rates) I am also wondering, should it always be the lowest rate? I quite agree with this choice since it makes sure that it gets understood by every legacy station and it is much more robust, but how is it implemented in the field? https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... File src/wifi/model/minstrel-ht-wifi-manager.h (right): https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.h:143: uint8_t N_GROUPS = MAX_SUPPORTED_STREAMS * MAX_STREAM_GROUPS; //!< Number of groups Minstrel should consider. Why making them fixed now? Won't this cause problems?
Sign in to reply to this message.
On 2016/01/17 09:55:34, S. Deronne wrote: > Matias, > It looks already better, thanks for having handle this so quickly. > > I have mainly two remarks: > -> I think we should go for a merged Minstrel, so that legacy Minstrel can be > used in case HT is not supported. Ok, I'll work on merging both managers. I'm thinking on checking HT support at the start and setting a flag to use where needed. I'm also thinking on a major refactor so as to make the code clearer. The main change would be to have a rate table emulating the mrr chain and then avoid all those if else in DoReportDataFail. But perhaps this should be on another patch. > -> channel width and GI seems fixed, so I only see one group being used. My fault, I correct it. I'll upload a new patch with the merge and other corrections as soon as possible. > > https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... > File src/wifi/model/minstrel-ht-wifi-manager.cc (right): > > https://codereview.appspot.com/283960043/diff/1/src/wifi/model/minstrel-ht-wi... > src/wifi/model/minstrel-ht-wifi-manager.cc:588: { > This was the initial thought of Tom (I saw that in his comments from Ghada's > proposal), so I suggest to merge those two managers. > > https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... > File src/wifi/model/minstrel-ht-wifi-manager.cc (right): > > https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... > src/wifi/model/minstrel-ht-wifi-manager.cc:20: * Ghada Badawy > <mailto:gbadawy@gmail.com> > Feel free to add you as author, so that interested people can easily contact you > in the future. > > https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... > src/wifi/model/minstrel-ht-wifi-manager.cc:27: * 2) 40Mhz can't fall back to > 20MHz > I testing with channel width 40 MHz and it seems indeed not testing rate of 20 > MHz, so it stays fixed to 40 MHz channel. > > I can live with that for the moment since our error models do not model (yet) > channel aggregation, so basically you will get same error rate at 20 MHz and at > 40 MHz, so it would make sense to keep a fixed channel. > But if once we do support dynamic channel width selection, I wonder if this will > still be ok... > > And what about SGI? I see the same thing happening (fixed GI): previous comments > apply also to GI selection. > > https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... > src/wifi/model/minstrel-ht-wifi-manager.cc:354: * FIXME In MinstrelHT Lowest > baserate is not used > I suggest to indicate a reference to the Linux implementation in order to > explain this choice. > > https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... > src/wifi/model/minstrel-ht-wifi-manager.cc:592: //Using the lowest non-HT rate. > I suggest to explain why non-HT is used for RTS frames (maybe point to a > reference in the standard and tell that we do not currently support cases where > RTS is transmitted using HT rates) > > I am also wondering, should it always be the lowest rate? > I quite agree with this choice since it makes sure that it gets understood by > every legacy station and it is much more robust, but how is it implemented in > the field? > > https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... > File src/wifi/model/minstrel-ht-wifi-manager.h (right): > > https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... > src/wifi/model/minstrel-ht-wifi-manager.h:143: uint8_t N_GROUPS = > MAX_SUPPORTED_STREAMS * MAX_STREAM_GROUPS; //!< Number of groups Minstrel should > consider. > Why making them fixed now? Won't this cause problems?
Sign in to reply to this message.
https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... File src/wifi/model/minstrel-ht-wifi-manager.cc (right): https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.cc:20: * Ghada Badawy <gbadawy@gmail.com> On 2016/01/17 09:55:34, S. Deronne wrote: > Feel free to add you as author, so that interested people can easily contact you > in the future. Done https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.cc:27: * 2) 40Mhz can't fall back to 20MHz On 2016/01/17 09:55:34, S. Deronne wrote: > I testing with channel width 40 MHz and it seems indeed not testing rate of 20 > MHz, so it stays fixed to 40 MHz channel. > > I can live with that for the moment since our error models do not model (yet) > channel aggregation, so basically you will get same error rate at 20 MHz and at > 40 MHz, so it would make sense to keep a fixed channel. > But if once we do support dynamic channel width selection, I wonder if this will > still be ok... > > And what about SGI? I see the same thing happening (fixed GI): previous comments > apply also to GI selection. Yes, I uploaded a version missing some changes to make that work, sorry. Next patch will adapt both. I'm removing the comment. https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.cc:354: * FIXME In MinstrelHT Lowest baserate is not used On 2016/01/17 09:55:33, S. Deronne wrote: > I suggest to indicate a reference to the Linux implementation in order to > explain this choice. Done. I remove the FIXME https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.cc:592: //Using the lowest non-HT rate. On 2016/01/17 09:55:33, S. Deronne wrote: > I suggest to explain why non-HT is used for RTS frames (maybe point to a > reference in the standard and tell that we do not currently support cases where > RTS is transmitted using HT rates) > > I am also wondering, should it always be the lowest rate? > I quite agree with this choice since it makes sure that it gets understood by > every legacy station and it is much more robust, but how is it implemented in > the field? No, it should not be the lowest rate. I just follow what was done in other managers. According to the standard: "A frame other than a BlockAckReq or BlockAck that is carried in a non-HT PPDU shall be transmitted by the STA using a rate no higher than the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate or non-HT reference rate (see 9.7.9) of the previously transmitted frame that was directed to the same receiving STA. If no rate in the BSSBasicRateSet parameter meets these conditions, the control frame shall be transmitted at a rate no higher than the highest mandatory rate of the attached PHY that is less than or equal to the rate or non-HT reference rate (see 9.7.9) of the previously transmitted frame that was directed to the same receiving STA." I'm implementing this option now. https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... File src/wifi/model/minstrel-ht-wifi-manager.h (right): https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.h:143: uint8_t N_GROUPS = MAX_SUPPORTED_STREAMS * MAX_STREAM_GROUPS; //!< Number of groups Minstrel should consider. On 2016/01/17 09:55:34, S. Deronne wrote: > Why making them fixed now? Won't this cause problems? I'm not sure what's the best option here. As I explain in the message, the phy configuration may change through the execution and I need some value to start the arrays. So I follow what is done on linux implementation, where these max values are fixed. Another option is to put them as arguments of the manager. What do you think?
Sign in to reply to this message.
https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... File src/wifi/model/minstrel-ht-wifi-manager.h (right): https://codereview.appspot.com/283960043/diff/20001/src/wifi/model/minstrel-h... src/wifi/model/minstrel-ht-wifi-manager.h:143: uint8_t N_GROUPS = MAX_SUPPORTED_STREAMS * MAX_STREAM_GROUPS; //!< Number of groups Minstrel should consider. I can live with this as long as this works as expected.
Sign in to reply to this message.
Patch Set 3 includes the corrections to the second review done by Sebastien but also some other improvements: - Enable SGI and chWidth adaptation - Improve RTS rate election. Add GetNonHtReferenceRate function to wifi-mode (needed for RTS rate election) - Change throughput calculation when probability is less than 10% or more than 90%. Copy what is done in linux - Modify how sampling is made (based on Linux implementation). This make the algorithm to react better to changes. - In ad-hoc mode when the station supports HT install all MCSs supported. This was a bug that make HT rate adaptation not to work when using ad-hoc mode
Sign in to reply to this message.
In this patch set there is still missing two important things: - no fallback to legacy minstrel if HT is not supported - no aggregation support. some problems arises if aggregation is used, mainly because of retries.
Sign in to reply to this message.
On 2016/02/10 15:45:11, Matías Richart wrote: > Patch Set 3 includes the corrections to the second review done by Sebastien but > also some other improvements: > - Enable SGI and chWidth adaptation > - Improve RTS rate election. Add GetNonHtReferenceRate function to wifi-mode > (needed for RTS rate election) > - Change throughput calculation when probability is less than 10% or more than > 90%. Copy what is done in linux > - Modify how sampling is made (based on Linux implementation). This make the > algorithm to react better to changes. > - In ad-hoc mode when the station supports HT install all MCSs supported. This > was a bug that make HT rate adaptation not to work when using ad-hoc mode Matias, was it not agreed to go for the extension of the legacy Minstrel iso adding a new HT Minstrel class, in order to support "fallback" to legacy Minstrel?
Sign in to reply to this message.
On 2016/02/14 20:43:33, S. Deronne wrote: > On 2016/02/10 15:45:11, Matías Richart wrote: > > Patch Set 3 includes the corrections to the second review done by Sebastien > but > > also some other improvements: > > - Enable SGI and chWidth adaptation > > - Improve RTS rate election. Add GetNonHtReferenceRate function to wifi-mode > > (needed for RTS rate election) > > - Change throughput calculation when probability is less than 10% or more than > > 90%. Copy what is done in linux > > - Modify how sampling is made (based on Linux implementation). This make the > > algorithm to react better to changes. > > - In ad-hoc mode when the station supports HT install all MCSs supported. This > > was a bug that make HT rate adaptation not to work when using ad-hoc mode > > Matias, was it not agreed to go for the extension of the legacy Minstrel iso > adding a new HT Minstrel class, in order to support "fallback" to legacy > Minstrel? Yes, your are right. I'm working on that.
Sign in to reply to this message.
|
