[Ns-bugs] [Bug 991] InterferenceHelper assertion failure (cond="current >= previous")

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=991





--- Comment #6 from Kirill Andreev <andreev at iitp.ru>  2010-09-10 06:53:44 EDT ---
(In reply to comment #3)
> I'm still trying to work out how to write the test case (haven't written one
> for NS-3 yet).
> 
> In terms of bug fix - I think we can probably just change AppendEvent to clean
> up m_niChanges every time AppendEvent is called, but i have no idea why the
> separate case for m_rxing is there.
> 


Adding special case of m_rxing is need for the following:
  - when you are not receiving a packet, you need not remember
    all NIChanges before current moment.
  - when you are receiving a packet, you need to remember all
    NiChanges to calculate PER properly.
So, m_rxing keeps a list of NiChanges as small as possible.

All events that happen in the future MUST be stored in NiChanges.



> I also think maybe NiChanges should also be a std::list<NiChange> instead of a
> std::vector - I don't seem to see any random access to instances of it, and a
> std::list

std::list was rejected because it works too slow, vector keeps sorted by time
NI changes, and going through the list is slower than going through the vector
(GetPosition method loses performance if you use a list, because it uses binary
search. I have played with profiler a lot, and I have tried to use a list.
Deleting the element kills performance much less than binary search improves
it).


> might make deletion a bit more efficient. (Would the efficiency
> concern be the reason why we don't clean up m_niChanges every time?)

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.