Bugzilla – Full Text Bug Listing |
Summary: | Simulator::Now() Updating and Simulator::Stop() | ||
---|---|---|---|
Product: | ns-3 | Reporter: | Joe Kopena <tjkopena> |
Component: | core | Assignee: | Craig Dowell <craigdo> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ns-bugs |
Priority: | P1 | ||
Version: | pre-release | ||
Hardware: | All | ||
OS: | All | ||
Attachments: | get rid of m_stopAt |
Description
Joe Kopena
2008-06-20 16:40:24 EDT
(In reply to comment #0) > Currently, when you use Simulator::Stop(), the simulator time is not updated at > the end of the simulation. It remains at the time of the last event to be > processed. For example, the following will print "0ns": > > Simulator::Stop(Seconds(4)); > Simulator::Run(); > std::cout << Simulator::Now() << std::endl; > > This is non-intuitive, and a potential annoyance for some add-on modules which > do not necessarily know when the simulation script set the simulation to end. > Example tasks affected by this include calculating partial traffic, updating > final positions, etc. A potential workaround is the following, which will > print the expected "4ns": > > Simulator::Schedule(Seconds(4), &Simulator::Stop); > Simulator::Run(); > std::cout << Simulator::Now() << std::endl; > > But, this has the important downside of allowing some events scheduled at the > same time to be executed before this event is processed. > > I believe the fix is as simple as setting m_currentTs to m_stopAt when the > simulation ends because m_stopAt > NextTs(), but am not 100% convinced. While the proposed change seems fairly intuitive, I am worried about potential breakage in the case where you call Simulator::Run multiple times. I have to ask, though, why does't Simulator::Stop (delay) not just schedule an event to call Stop at the right time ? That would be even simpler and would solve this problem. Patch attached. > > Thx > Created attachment 330 [details]
get rid of m_stopAt
(In reply to comment #2) > Created an attachment (id=330) [details] > get rid of m_stopAt > So, to summarize, this patch passes all tests and regressions. I also believe that it gets rid of the unused m_stopAt variable in the realtime scheduler (that variable was read but never set to anything but zero) and results in a final code decrease. Seems like low risk and fairly ok. assigning to craig to decide whether to apply or not. |