|
Bugzilla – Full Text Bug Listing |
| Summary: | ideal-wifi-manager-example crashes when NSS > 1 | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | sebastien.deronne |
| Component: | wifi | Assignee: | Matías Richart <matis18> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | matis18, ns-bugs, redieteab.orange, tomh |
| Priority: | P2 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
Select the nss according to the selected mode
alternative patch Fix bug and include checking for SS support at the receiver Patch to test different SS at sender and receiver in ideal Fix bug and include checking for SS support at the receiver Patch to extend ideal example example to replace ideal and minstrelht examples |
||
I guess this can be assigned to Tom :-) Please note that I still need to deliver a small fix to handle guard interval in nanoseconds in ideal wifi manager. I will deliver the patch later today. Created attachment 2771 [details]
Select the nss according to the selected mode
The problem is that the nss used does not always correspond to the mode selected.
I attach a patch.
(In reply to Matías Richart from comment #2) > Created attachment 2771 [details] > Select the nss according to the selected mode > > The problem is that the nss used does not always correspond to the mode > selected. > I attach a patch. Thanks, it's working like a charm :-) Is there absolutely a need to keep 2 variables to store nss? (In reply to sebastien.deronne from comment #3) > (In reply to Matías Richart from comment #2) > > Created attachment 2771 [details] > > Select the nss according to the selected mode > > > > The problem is that the nss used does not always correspond to the mode > > selected. > > I attach a patch. > > Thanks, it's working like a charm :-) > Is there absolutely a need to keep 2 variables to store nss? It is not. A uploaded an alternative. Created attachment 2772 [details]
alternative patch
(In reply to Matías Richart from comment #5) > Created attachment 2772 [details] > alternative patch I did not check whether this works, but I have 2 questions: 1/ We do this change already a bit above in the code, why this is needed once again there? 2/ I see from ideal that we pick the highest supported tx spatial stream of the transmitter without checking what the receiver does support. Is this correct? Was this ever tested against a 4 Tx emitter and a 3 Rx receiver? I see this also in your change and I think the case of unequal Tx-Rx pairs is not taken into account. (In reply to sebastien.deronne from comment #6) > (In reply to Matías Richart from comment #5) > > Created attachment 2772 [details] > > alternative patch > > I did not check whether this works, but I have 2 questions: > 1/ We do this change already a bit above in the code, why this is needed > once again there? The code I added is to get the nss of the "maxMode" selected in the loop. Which doesn't necessarily matches the last nss picked in the loop. > 2/ I see from ideal that we pick the highest supported tx spatial stream of > the transmitter without checking what the receiver does support. Is this > correct? Was this ever tested against a 4 Tx emitter and a 3 Rx receiver? I > see this also in your change and I think the case of unequal Tx-Rx pairs is > not taken into account. You are right, it will fail. I can work on that. (In reply to Matías Richart from comment #7) > (In reply to sebastien.deronne from comment #6) > > (In reply to Matías Richart from comment #5) > > > Created attachment 2772 [details] > > > alternative patch > > > > I did not check whether this works, but I have 2 questions: > > 1/ We do this change already a bit above in the code, why this is needed > > once again there? > > The code I added is to get the nss of the "maxMode" selected in the loop. > Which doesn't necessarily matches the last nss picked in the loop. Ok sorry, my fault. > > > 2/ I see from ideal that we pick the highest supported tx spatial stream of > > the transmitter without checking what the receiver does support. Is this > > correct? Was this ever tested against a 4 Tx emitter and a 3 Rx receiver? I > > see this also in your change and I think the case of unequal Tx-Rx pairs is > > not taken into account. > > You are right, it will fail. > I can work on that. Thanks. Not sure there is an obvious call, I am not sure we store the supported number of streams so far. If you miss time let me know and I'll add this. Created attachment 2773 [details] Fix bug and include checking for SS support at the receiver The patch proposes to try all possible NSSs in VHT that are also supported by the receiver. It also includes the fix for bug 2606. I'll also attach a test patch. Created attachment 2774 [details]
Patch to test different SS at sender and receiver in ideal
A simple patch to try the new proposal.
We should extend the example to test all possible combinations.
My test: ./waf --run "ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=20 --shortGuard=0 --nss=4"
(In reply to Matías Richart from comment #10) > Created attachment 2774 [details] > Patch to test different SS at sender and receiver in ideal > > A simple patch to try the new proposal. > We should extend the example to test all possible combinations. > > My test: ./waf --run "ideal-wifi-manager-example --standard=802.11n-5GHz > --channelWidth=20 --shortGuard=0 --nss=4" Thanks. I do not understand why you do those checks for VHT only? FYI I've pushed your fix for bug 2606. (In reply to sebastien.deronne from comment #11) > (In reply to Matías Richart from comment #10) > > Created attachment 2774 [details] > > Patch to test different SS at sender and receiver in ideal > > > > A simple patch to try the new proposal. > > We should extend the example to test all possible combinations. > > > > My test: ./waf --run "ideal-wifi-manager-example --standard=802.11n-5GHz > > --channelWidth=20 --shortGuard=0 --nss=4" > > Thanks. > I do not understand why you do those checks for VHT only? Do you mean the NSS check? In HT, we have a different mode indexes for each value of NSS. So, as we use GetMcsSupported (station) we know the mode (and NSS) is supported by the receiver. In VHT, the same mode index can identify different NSSs, so I have to try all possible NSSs and check if the receiver supports them. > > FYI I've pushed your fix for bug 2606. Great! (In reply to Matías Richart from comment #12) > (In reply to sebastien.deronne from comment #11) > > (In reply to Matías Richart from comment #10) > > > Created attachment 2774 [details] > > > Patch to test different SS at sender and receiver in ideal > > > > > > A simple patch to try the new proposal. > > > We should extend the example to test all possible combinations. > > > > > > My test: ./waf --run "ideal-wifi-manager-example --standard=802.11n-5GHz > > > --channelWidth=20 --shortGuard=0 --nss=4" > > > > Thanks. > > I do not understand why you do those checks for VHT only? > > Do you mean the NSS check? > In HT, we have a different mode indexes for each value of NSS. So, as we use > GetMcsSupported (station) we know the mode (and NSS) is supported by the > receiver. > > In VHT, the same mode index can identify different NSSs, so I have to try > all possible NSSs and check if the receiver supports them. > Indeed, thanks. Can't we imagine to have some parameters in the example to configure unequal nss values iso of hardcoded ones? > > > > FYI I've pushed your fix for bug 2606. > > Great! (In reply to sebastien.deronne from comment #13) > (In reply to Matías Richart from comment #12) > > (In reply to sebastien.deronne from comment #11) > > > (In reply to Matías Richart from comment #10) > > > > Created attachment 2774 [details] > > > > Patch to test different SS at sender and receiver in ideal > > > > > > > > A simple patch to try the new proposal. > > > > We should extend the example to test all possible combinations. > > > > > > > > My test: ./waf --run "ideal-wifi-manager-example --standard=802.11n-5GHz > > > > --channelWidth=20 --shortGuard=0 --nss=4" > > > > > > Thanks. > > > I do not understand why you do those checks for VHT only? > > > > Do you mean the NSS check? > > In HT, we have a different mode indexes for each value of NSS. So, as we use > > GetMcsSupported (station) we know the mode (and NSS) is supported by the > > receiver. > > > > In VHT, the same mode index can identify different NSSs, so I have to try > > all possible NSSs and check if the receiver supports them. > > > > Indeed, thanks. > Can't we imagine to have some parameters in the example to configure unequal > nss values iso of hardcoded ones? Yes, sure. This was a quick workaround to test the proposal. I'll work on that. I'm thinking also to include more parameters to have unequal channel widths and guard intervals. > > > > > > > FYI I've pushed your fix for bug 2606. > > > > Great! (In reply to Matías Richart from comment #14) > (In reply to sebastien.deronne from comment #13) > > (In reply to Matías Richart from comment #12) > > > (In reply to sebastien.deronne from comment #11) > > > > (In reply to Matías Richart from comment #10) > > > > > Created attachment 2774 [details] > > > > > Patch to test different SS at sender and receiver in ideal > > > > > > > > > > A simple patch to try the new proposal. > > > > > We should extend the example to test all possible combinations. > > > > > > > > > > My test: ./waf --run "ideal-wifi-manager-example --standard=802.11n-5GHz > > > > > --channelWidth=20 --shortGuard=0 --nss=4" > > > > > > > > Thanks. > > > > I do not understand why you do those checks for VHT only? > > > > > > Do you mean the NSS check? > > > In HT, we have a different mode indexes for each value of NSS. So, as we use > > > GetMcsSupported (station) we know the mode (and NSS) is supported by the > > > receiver. > > > > > > In VHT, the same mode index can identify different NSSs, so I have to try > > > all possible NSSs and check if the receiver supports them. > > > > > > > Indeed, thanks. > > Can't we imagine to have some parameters in the example to configure unequal > > nss values iso of hardcoded ones? > > Yes, sure. This was a quick workaround to test the proposal. > I'll work on that. I'm thinking also to include more parameters to have > unequal channel widths and guard intervals. > > > > > > > > > > > FYI I've pushed your fix for bug 2606. > > > > > > Great! Thanks for taking care of that. To be delivered once ideal example is updated by Matias (In reply to sebastien.deronne from comment #16) > To be delivered once ideal example is updated by Matias I uploaded a new patch with some improvements (in initialization there was missing the loop for NSS in VHT). I also added a patch for ideal example which allows to have different standard, channel width, SGI and NSS in sender and receiver. I did not yet test all possible combinations. However, I noticed one discrepancy with previous version of the manager. When using ac and NSS=4 in both sides ideal selects a lower rate. As the new ideal code, tests all possible values for nss, it founds a rate with lower nss but with higher threshold and selects that. So, i don't know if this is a bug or the correct behavior of ideal. Perhaps Tom can help with this. Created attachment 2777 [details]
Fix bug and include checking for SS support at the receiver
Created attachment 2778 [details]
Patch to extend ideal example
(In reply to Matías Richart from comment #17) > (In reply to sebastien.deronne from comment #16) > > To be delivered once ideal example is updated by Matias > > I uploaded a new patch with some improvements (in initialization there was > missing the loop for NSS in VHT). > > I also added a patch for ideal example which allows to have different > standard, channel width, SGI and NSS in sender and receiver. > > I did not yet test all possible combinations. > However, I noticed one discrepancy with previous version of the manager. > When using ac and NSS=4 in both sides ideal selects a lower rate. > As the new ideal code, tests all possible values for nss, it founds a rate > with lower nss but with higher threshold and selects that. So, i don't know > if this is a bug or the correct behavior of ideal. > Perhaps Tom can help with this. Thanks a lot. Can we also adapt minstrel-ht example, or maybe merge them since they are quite similar? Maybe it would also be good to add an option to be in infrastructure or adhoc? I can do it this week if you miss time for this final improvement. Could you detail a bit more the issue you encoutered? (In reply to sebastien.deronne from comment #20) > (In reply to Matías Richart from comment #17) > > (In reply to sebastien.deronne from comment #16) > > > To be delivered once ideal example is updated by Matias > > > > I uploaded a new patch with some improvements (in initialization there was > > missing the loop for NSS in VHT). > > > > I also added a patch for ideal example which allows to have different > > standard, channel width, SGI and NSS in sender and receiver. > > > > I did not yet test all possible combinations. > > However, I noticed one discrepancy with previous version of the manager. > > When using ac and NSS=4 in both sides ideal selects a lower rate. > > As the new ideal code, tests all possible values for nss, it founds a rate > > with lower nss but with higher threshold and selects that. So, i don't know > > if this is a bug or the correct behavior of ideal. > > Perhaps Tom can help with this. > > Thanks a lot. > > Can we also adapt minstrel-ht example, or maybe merge them since they are > quite similar? > Maybe it would also be good to add an option to be in infrastructure or > adhoc? > I can do it this week if you miss time for this final improvement. I can look at it by the end of the week, not sooner :( > > Could you detail a bit more the issue you encoutered? With 802.11ac and nss=4 (same conf in both sides) I get lower rates. For example, with the new code the higher data rate selected is 260mbps while before was 312. This is because with the old code only nss=4 was used and the rate selected was VhtMcs8 with nss=4. Now, as ideal manager tests all possible values of nss, it founds that the "best" rate (the one with higher snr threshold) is VhtMcs9 with nss=3, which gets a lower data rate. OK thanks, depending on my availabilities, I'll try to help as well. (In reply to sebastien.deronne from comment #22) > OK thanks, depending on my availabilities, I'll try to help as well. I started working on the example. If you have time, please focus on the VhtMcs8 with nss=4 case. By the way, did you try running with a longer stepTime? Example is almost ready. What we might do is deliver the patch + example and open a new thread if bug is confirmed. (In reply to sebastien.deronne from comment #24) > By the way, did you try running with a longer stepTime? I don't. Is it generating problems? > > Example is almost ready. > > What we might do is deliver the patch + example and open a new thread if bug > is confirmed. I agree. Regarding the possible bug the difference is caused because the SNR threshold for the "same" rate with different NSS values is always the same. In the example I tested what is happening is: VhtMcs8 gets a SNR threshold of 600 (for nss: 1,2,3 and 4) VhtMcs9 gets a SNR threshold of 900 (for nss: 1,2 and 3, nss=4 is invalid in this case) So ideal manager selects Vhtmcs9 with nss=3. Before the proposed patch, as we did not consider all possible values of NSS, ideal was choosing VhtMcs8 with nss=4 which provides a higher data rate than VhtMcs9, nss=3. In summary, I think ideal is working as expected. What I do not know is if different NSSs should give different SNRs. Created attachment 2783 [details]
example to replace ideal and minstrelht examples
I merged Ideal and MinstrelHt examples since both were quite duplicates. I took Matias's improvements to select different configuration on server and on client.
This also enables to test all managers and it is no longer limited to Ideal and MinstrelHt.
(In reply to Matías Richart from comment #25) > (In reply to sebastien.deronne from comment #24) > > By the way, did you try running with a longer stepTime? > > I don't. Is it generating problems? > > > > > Example is almost ready. > > > > What we might do is deliver the patch + example and open a new thread if bug > > is confirmed. > > I agree. > > Regarding the possible bug the difference is caused because the SNR > threshold for the "same" rate with different NSS values is always the same. > > In the example I tested what is happening is: > VhtMcs8 gets a SNR threshold of 600 (for nss: 1,2,3 and 4) > VhtMcs9 gets a SNR threshold of 900 (for nss: 1,2 and 3, nss=4 is invalid in > this case) > > So ideal manager selects Vhtmcs9 with nss=3. > Before the proposed patch, as we did not consider all possible values of > NSS, ideal was choosing VhtMcs8 with nss=4 which provides a higher data rate > than VhtMcs9, nss=3. > > In summary, I think ideal is working as expected. What I do not know is if > different NSSs should give different SNRs. Should ideal not search for the highest PHY rate iso the highest MCS? (In reply to Matías Richart from comment #25) > (In reply to sebastien.deronne from comment #24) > > By the way, did you try running with a longer stepTime? > > I don't. Is it generating problems? > > > > > Example is almost ready. > > > > What we might do is deliver the patch + example and open a new thread if bug > > is confirmed. > > I agree. > > Regarding the possible bug the difference is caused because the SNR > threshold for the "same" rate with different NSS values is always the same. > > In the example I tested what is happening is: > VhtMcs8 gets a SNR threshold of 600 (for nss: 1,2,3 and 4) > VhtMcs9 gets a SNR threshold of 900 (for nss: 1,2 and 3, nss=4 is invalid in > this case) > > So ideal manager selects Vhtmcs9 with nss=3. > Before the proposed patch, as we did not consider all possible values of > NSS, ideal was choosing VhtMcs8 with nss=4 which provides a higher data rate > than VhtMcs9, nss=3. > > In summary, I think ideal is working as expected. What I do not know is if > different NSSs should give different SNRs. Hello Matías, Sébastien, At the risk of beating a dead horse, here is a potential explanation: from a signal processing point of view, transmitting fewer NSSs over the same number of transmit antennas should result in greater diversity and thus greater (combined) SNR. Cheers, Rediet (In reply to sebastien.deronne from comment #27) > (In reply to Matías Richart from comment #25) > > (In reply to sebastien.deronne from comment #24) > > > By the way, did you try running with a longer stepTime? > > > > I don't. Is it generating problems? > > > > > > > > Example is almost ready. > > > > > > What we might do is deliver the patch + example and open a new thread if bug > > > is confirmed. > > > > I agree. > > > > Regarding the possible bug the difference is caused because the SNR > > threshold for the "same" rate with different NSS values is always the same. > > > > In the example I tested what is happening is: > > VhtMcs8 gets a SNR threshold of 600 (for nss: 1,2,3 and 4) > > VhtMcs9 gets a SNR threshold of 900 (for nss: 1,2 and 3, nss=4 is invalid in > > this case) > > > > So ideal manager selects Vhtmcs9 with nss=3. > > Before the proposed patch, as we did not consider all possible values of > > NSS, ideal was choosing VhtMcs8 with nss=4 which provides a higher data rate > > than VhtMcs9, nss=3. > > > > In summary, I think ideal is working as expected. What I do not know is if > > different NSSs should give different SNRs. > > Should ideal not search for the highest PHY rate iso the highest MCS? From what I understand, ideal searches for the rate which gives higher SNR threshold (the rate which has higher minimum SNR for the given BER). I think that the rationale behind this is that this would give the highest phy rate. But, as I mentioned, this is not the case when you add the NSS variable. Perhaps Tom has a better view about this. (In reply to Matías Richart from comment #29) > (In reply to sebastien.deronne from comment #27) > > (In reply to Matías Richart from comment #25) > > > (In reply to sebastien.deronne from comment #24) > > > > By the way, did you try running with a longer stepTime? > > > > > > I don't. Is it generating problems? > > > > > > > > > > > Example is almost ready. > > > > > > > > What we might do is deliver the patch + example and open a new thread if bug > > > > is confirmed. > > > > > > I agree. > > > > > > Regarding the possible bug the difference is caused because the SNR > > > threshold for the "same" rate with different NSS values is always the same. > > > > > > In the example I tested what is happening is: > > > VhtMcs8 gets a SNR threshold of 600 (for nss: 1,2,3 and 4) > > > VhtMcs9 gets a SNR threshold of 900 (for nss: 1,2 and 3, nss=4 is invalid in > > > this case) > > > > > > So ideal manager selects Vhtmcs9 with nss=3. > > > Before the proposed patch, as we did not consider all possible values of > > > NSS, ideal was choosing VhtMcs8 with nss=4 which provides a higher data rate > > > than VhtMcs9, nss=3. > > > > > > In summary, I think ideal is working as expected. What I do not know is if > > > different NSSs should give different SNRs. > > > > Should ideal not search for the highest PHY rate iso the highest MCS? > > From what I understand, ideal searches for the rate which gives higher SNR > threshold (the rate which has higher minimum SNR for the given BER). > I think that the rationale behind this is that this would give the highest > phy rate. But, as I mentioned, this is not the case when you add the NSS > variable. > Perhaps Tom has a better view about this. I agree that the current code seems to have been designed with this goal in mind, not taking into consideration NSS or channel bonding (which were not supported when Ideal was originally written). I think that the logic may need to be rewritten to optimize maximum phy rate for the available SNR, or to perhaps approximate the logic of minstrel HT or other dynamic rate controls in terms of how they prioritize rates to search and select. That is something we should indeed keep in mind. Nevertheless I think the scope of this bug has been addressed and I suggest to deliver code changes and close it. Fix pushed in changeset 12686:503f88506643 and example pushed in changeset 12687:05d210a15753 |
I am adding ideal-wifi-manager-example to regression and ideal wifi manager tests are crashing. List of CRASHed tests: src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=20 --shortGuard=0 --nss=2 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=20 --shortGuard=0 --nss=3 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=20 --shortGuard=0 --nss=4 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=20 --shortGuard=1 --nss=2 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=20 --shortGuard=1 --nss=3 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=20 --shortGuard=1 --nss=4 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=40 --shortGuard=0 --nss=2 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=40 --shortGuard=0 --nss=3 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=40 --shortGuard=0 --nss=4 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=40 --shortGuard=1 --nss=2 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=40 --shortGuard=1 --nss=3 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=40 --shortGuard=1 --nss=4 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=20 --shortGuard=0 --nss=2 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=20 --shortGuard=0 --nss=3 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=20 --shortGuard=0 --nss=4 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=20 --shortGuard=1 --nss=2 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=20 --shortGuard=1 --nss=3 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=20 --shortGuard=1 --nss=4 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=40 --shortGuard=0 --nss=2 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=40 --shortGuard=0 --nss=3 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=40 --shortGuard=0 --nss=4 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=40 --shortGuard=1 --nss=2 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=40 --shortGuard=1 --nss=3 src/wifi/examples/ideal-wifi-manager-example --standard=802.11n-5GHz --channelWidth=40 --shortGuard=1 --nss=4 ./waf --run "ideal-wifi-manager-example --standard=802.11n-2.4GHz --channelWidth=20 --shortGuard=0 --nss=2 msg="MCS value does not match NSS value: MCS = 7, NSS = 2", file=../src/wifi/model/wifi-phy.cc, line=2471 The same tests are passing fine with Minstrel HT.