Bugzilla – Bug 625
Wrong calculation of GetAccessGrantStart in DcfManager
Last modified: 2009-07-16 06:20:10 EDT
You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=516) [details] Proposed fix DcfManager checks that it is not in RX mode by comparing last RX end and last RX start "if (m_lastRxEnd >= m_lastRxStart)", but in case of hidden stations these moments of time may be equal, and wrong decision will be made (for example, we have started to receive a frame exactly after previous received frame) (see figure). So, to prevent this situation it is better to check m_rxing flag. Also the proposed fix does not change any regression or unit tests. stations: 1 2 3 frames at station 2: |frame from 1| |frame from 3| ^ ^ these 2 moments may be equal if stations 1 and 3 don't hear each other
Is this fixing an actual bug ? If so, could you try to provide a new testcase which shows the bug ?
Created an attachment (id=534) [details] Propose fix + test You can see, that without path expected access time is the same as in the previous test
I have written a tescase, but in new patch I have removed NS_ASSERT () in dcf-manager.cc line 580, because when I have run my test, this ASSERT has failed (and using this ASSERT I have observed this bug). Also we can see, that expected access is wrong when we receive second frame exactly at the moment of endRx of the first frame (this is possible with hidden terminals)
(In reply to comment #3) > I have written a tescase, but in new patch I have removed NS_ASSERT () in > dcf-manager.cc line 580, because when I have run my test, this ASSERT has > failed (and using this ASSERT I have observed this bug). Also we can see, that > expected access is wrong when we receive second frame exactly at the moment of > endRx of the first frame (this is possible with hidden terminals) > I really don't understand why you are removing that ASSERT (which you introduced yourself previously). Can you explain better what triggers that assert to fail ?
(In reply to comment #4) > (In reply to comment #3) > > I have written a tescase, but in new patch I have removed NS_ASSERT () in > > dcf-manager.cc line 580, because when I have run my test, this ASSERT has > > failed (and using this ASSERT I have observed this bug). Also we can see, that > > expected access is wrong when we receive second frame exactly at the moment of > > endRx of the first frame (this is possible with hidden terminals) > > > > I really don't understand why you are removing that ASSERT (which you > introduced yourself previously). Can you explain better what triggers that > assert to fail ? > I have removed this ASSERT just to show, taht the tescase itself fails, rather than this ASSERT. So, it shall not be removed at all.
ack :) feel free to commit then. (Do you have commit powers ?)
(In reply to comment #6) > ack :) > > feel free to commit then. (Do you have commit powers ?) > No, I have no commit powers.
changeset: f17f12944235