|
Bugzilla – Full Text Bug Listing |
| Summary: | Changing the rate of onOffApplication might stop transmission | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Ra <ravitejac> |
| Component: | applications | Assignee: | George Riley <riley> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | bswenson3, ns-bugs, tommaso.pecorella |
| Priority: | P1 | ||
| Version: | ns-3-dev | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: |
place the file in scratch folder and run "./waf --run onOff-datarateChangeBug" to reproduce the bug.
bugfix |
||
Created attachment 1711 [details]
bugfix
The bug is here:
void OnOffApplication::CancelEvents ()
{
NS_LOG_FUNCTION (this);
if (m_sendEvent.IsRunning ())
{ // Cancel the pending send packet event
// Calculate residual bits since last packet sent
Time delta (Simulator::Now () - m_lastStartTime);
int64x64_t bits = delta.To (Time::S) * m_cbrRate.GetBitRate ();
m_residualBits += bits.GetHigh ();
}
Simulator::Cancel (m_sendEvent);
Simulator::Cancel (m_startStopEvent);
}
If m_cbrRate is changed at the wrong moment, m_residualBits can become larger than m_pktSize * 8. Hence the ScheduleNextTx will schedule the next transmission to an extremely large time.
And the application will seems to stop.
The patch fixes the bug in a rather dirty (but effective) way
This looks good to me. Ignoring residual bits immediately after cbr change seems to be the best approach. Closed in changeset: 10438:32b7a66dbe7f |
Created attachment 1704 [details] place the file in scratch folder and run "./waf --run onOff-datarateChangeBug" to reproduce the bug. Changing the rate of onOffApplication at 5.0 seconds into the simulation results in no packets transmitted. However changing the rate at 5.001 seconds into the simulation seems to work OK. Please see line 204 in the attached file and change the value "5.0" to "5.001" to see the problem go away. You may run the attached file in the scratch folder with default values to reproduce the bug.