Kiran, I do not remember the specific details, but I believe that this trace was suppressed for performance reasons (wanting to avoid the additional Simulator::Schedule() event for every frame).  I believe that the original author of yans-wifi-phy.cc (Mathieu Lacage) made this decision.  I seem to recall that there may have been some other discussion of this many years ago in the tracker on another issue.

However, I do not know whether this suppression was based on some empirical profiling or whether it was just designed this way proactively.

I'll check with Mathieu whether he remembers the details of this.

There was a (not good ?) reason for that. In the yans Paper, in section 6.2:

While implementing the DCF would have been particularly easy if we had used a recurring timer that expired every slot, we chose to use the method described in [17] where the backoff timer duration is lazily calculated whenever needed, since it is claimed to have much better performance than the simpler recurring timer solution. In the bagrodia paper from [17], the reference is to section 5.1+5.2

Retrospectively, it would have been much simpler to schedule an end-of-tx event at the PHY layer and DIFS timers at the MAC layer to track the backoff. I personally would support such a change which would get rid of a lot of complexity at the MAC layer at the cost of a potentially slower simulation.

(In reply to Mathieu Lacage from comment #2)
> There was a (not good ?) reason for that. In the yans Paper, in section 6.2:
> 
> While implementing the DCF would have been particularly easy if we had used
> a recurring timer that expired every slot, we chose to use the method
> described in [17] where the backoff timer duration is lazily calculated
> whenever needed, since it is claimed to have much better performance than
> the simpler recurring timer solution. In the bagrodia paper from [17], the
> reference is to section 5.1+5.2
> 

> Retrospectively, it would have been much simpler to schedule an end-of-tx
> event at the PHY layer and DIFS timers at the MAC layer to track the
> backoff. I personally would support such a change which would get rid of a
> lot of complexity at the MAC layer at the cost of a potentially slower
> simulation.

Mathieu, so you believe its a good move to implement a PhyTxEnd trace? or the other way around(Higher priority for simulator performance)?

(In reply to Kiran Mathews from comment #3)

> Mathieu, so you believe its a good move to implement a PhyTxEnd trace?

Yes

We already suffer from slow simulation when a large amount of nodes are involved, so we should see how much this is affected.

Kiran, do you plan to try reworking the code as suggested by Mathieu so that we can eventually benchmark and evaluate impact on simulation speed? I do not think any other of us will have time to help on this. 

I am also scared we introduce regression here, since this code is quite stable and validated over the years.

Sebastien, currently I planned nothing, but I will give a try during my free time and incorporate the suggestions by Mathieu. Also, I cannot guarantee a deadline, is that okay?

(In reply to Kiran Mathews from comment #6)
> Sebastien, currently I planned nothing, but I will give a try during my free
> time and incorporate the suggestions by Mathieu. Also, I cannot guarantee a
> deadline, is that okay?

Of course, just post a patch when you have something that can be tested. I guess that if someone wants to help, he will comment here.

Fixed in changeset 948e9395269fb119ee4a916cb3a10aed0693397f