Bugzilla – Bug 230
Simulator::Now() Updating and Simulator::Stop()
Last modified: 2008-12-10 20:00:49 EST
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. Thx
(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.