|
Bugzilla – Full Text Bug Listing |
| Summary: | create trace source to trace the TXOP time that is actually used | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | sebastien.deronne |
| Component: | wifi | Assignee: | sebastien.deronne |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | ns-bugs, tomh |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
patch to add trace source in EdcaTxopN
new proposed patch |
||
|
Description
sebastien.deronne
2016-08-06 05:32:19 UTC
Tom, do you want the trace to be reset at the beginning of the txop and being updated to the quantity (Simulator::Now() - m_startTxopTime) at the transmission of a new QoS data frame during the same txop? (In reply to sebastien.deronne from comment #1) > Tom, do you want the trace to be reset at the beginning of the txop and > being updated to the quantity (Simulator::Now() - m_startTxopTime) at the > transmission of a new QoS data frame during the same txop? I think you are asking about what to report and when to report it. From a usage perspective, being able to construct a log of something like this (e.g.) node-id device-id frame-type Start-time (s) TXOP-duration (s) 6 0 AC_VI 1.000000000 0.003000000 and perhaps the quantity to report is to report the tuple (node-id, device-id, frame-type, start-time, TXOP-duration) every time that a TXOP concludes. I'd prefer to have actual TXOP consumed vs. maximum TXOP granted/allowed. I do not mind to work on providing a patch for the traced callback and an example usage once we find the spot in the code where this can be reported from. Created attachment 2525 [details]
patch to add trace source in EdcaTxopN
I have a first draft for this one.
IMO you should be able to fill in the info you need with this additional trace source in EdcaTxopN. Let me know what should be improved.
Any opinion on the current draft? (In reply to sebastien.deronne from comment #4) > Any opinion on the current draft? The signature looks OK; the documentation string should say 'start and duration' rather than 'start and stop' times. It looks like this will work as long as StartNext() is reliably called at the ending of all transmission TXOPs. That is, if MacLow () can somehow end a TXOP for other reasons without calling StartNext(), this will not work, and may lead to different TXOPs being blended together by this trace. What do you think? The other question I have is whether this trace should cover DCF as well. (In reply to Tom Henderson from comment #5) > (In reply to sebastien.deronne from comment #4) > > Any opinion on the current draft? > > The signature looks OK; the documentation string should say 'start and > duration' rather than 'start and stop' times. > > It looks like this will work as long as StartNext() is reliably called at > the ending of all transmission TXOPs. That is, if MacLow () can somehow end > a TXOP for other reasons without calling StartNext(), this will not work, > and may lead to different TXOPs being blended together by this trace. What > do you think? Not sure this can be possible for QoSData, or maybe we could check for the elapsed txop duration and if this is much bigger than the allowed txop limit, then trigger an assert? (In reply to Tom Henderson from comment #6) > The other question I have is whether this trace should cover DCF as well. Nope, TXOP is EDCA only. Created attachment 2624 [details]
new proposed patch
Updated previous patch with a better attribute description and added asserts to make sure we never violate the TXOP limit.
I had to update a test case where the transmission at the lowest speed was violating the TXOP boundary for a single PSDU. I will add a new thread in the tracker asap for having fragmentation in EdcaTxopN when we go over the TXOP limit.
Are there some further comments on the latest proposal? If no further comments, this should be delivered. changeset 12451:ac1e0cdd5ca9 |