|
Bugzilla – Full Text Bug Listing |
| Summary: | Support short guard interval durations in 802.11n | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | sebastien.deronne |
| Component: | wifi | Assignee: | Daniel L. <nikkipui> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | ns-bugs, sebastien.deronne, tomh, tommaso.pecorella |
| Priority: | P5 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
patch
patch v2 |
||
This bug may have been introduced when the Time constructors using doubles have been deprecated. An alternative system could be to use return Seconds (duration/1000.0); since Seconds (double x) exists. The two alternatives are more or less the same, but I do prefer the one proposed by Sébastien, purely because it avoids a double float->integer conversion. This kind of double conversion may lead to rounding nightmares. Speaking of, it could be a wise idea to change ALL the functions to NnanoSeconds, i.e.: - GetPlcpPreambleDurationMicroSeconds (payloadMode, preamble) - GetPlcpHeaderDurationMicroSeconds (payloadMode, preamble) - GetPlcpHtSigHeaderDurationMicroSeconds (payloadMode, preamble) - GetPlcpHtTrainingSymbolDurationMicroSeconds (payloadMode, preamble,txvector) - GetPayloadDurationMicroSeconds (size, txvector) and maybe others. Those should become: - GetPlcpPreambleDurationNanoSeconds etc. If I'm right, the original code idea was to avoid altogether to use a double... Speaking of... why GetPlcpPreambleDurationMicroSeconds ? Shouldn't it be GetPlcpPreambleDuration and return a Time ? WifiPhy::CalculateTxDuration is returning a Time. In that function a bunch of uint32_t are added, then a double (conversion to double), then a "Time" is created. What is the performance hit to sum a bunch of Time variables instead ? That would definitely make the code more foolproof and future-feature-proof. (In reply to Tommaso Pecorella from comment #2) > Speaking of... why GetPlcpPreambleDurationMicroSeconds ? > > Shouldn't it be GetPlcpPreambleDuration and return a Time ? > > WifiPhy::CalculateTxDuration is returning a Time. In that function a bunch > of uint32_t are added, then a double (conversion to double), then a "Time" > is created. > > What is the performance hit to sum a bunch of Time variables instead ? > > That would definitely make the code more foolproof and future-feature-proof. I agree, I decided to hold this patch on this issue (whether to look at more broadly avoiding Time to double conversions) Created attachment 1926 [details]
patch v2
Here is a new version of the patch (v2), which updates tx-duration-test in order to include the modifications in wifi-phy.
Tom, shouldn't we merge this patch before the upcoming ns-3.22 release and maybe create another bug report for Time to double conversions?
(In reply to sebastien.deronne from comment #4) > Created attachment 1926 [details] > patch v2 > > Here is a new version of the patch (v2), which updates tx-duration-test in > order to include the modifications in wifi-phy. > > Tom, shouldn't we merge this patch before the upcoming ns-3.22 release and > maybe create another bug report for Time to double conversions? I agree to separate these issues. I'll schedule this patch for application by next week if no other comments come in. patch v2 was pushed in changeset 11102:c5aba5d85686 |
Created attachment 1868 [details] patch When short guard interval is used in 802.11n, OFDM symbol durations are 3.6 microseconds instead of 4 microseconds. In WifiPhy::CalculateTxDuration, the returned precision is the microsecond. For example, the computed TX duration for the transmission of 12 OFDM symbols is equal to 12 * 3.6 = 43.2 microseconds. Nevertheless, since the returned precision is the microsecond, the method will return 43 microseconds. The provided patch enables to return a precision in nanoseconds, so that a duration of 43.2 microseconds will be strictly equal to 43.2 microseconds.