Bugzilla – Bug 1969
Support short guard interval durations in 802.11n
Last modified: 2014-12-12 15:00:49 EST
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.
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