Effect of forceTransmissionFinishTime on a VectorRecorder

33 views
Skip to first unread message

Michael Krane

unread,
Jan 24, 2015, 8:37:35 AM1/24/15
to omn...@googlegroups.com
Hi,

I'm trying to simulate a protocol where 2 different sources send over the same wire. To stop an ongoing Transmission and start the other I'm using:

gate("phy$o")->getTransmissionChannel()->forceTransmissionFinishTime(simTime());

sendDelayed
(buildPacket(TRAILER_PKG, pkgInfo),
            0
,
           
"phy$o");

In the .ini-File for the network I'm enabling record statistics:

**.result-recording-modes = all

In the simulation itself I'm getting this error:

<!> Error in module (ubs::Tx) P2pTestBench.tx (id=2) at event #18, t=0.000001024: VectorRecorder: Cannot record data with an earlier timestamp (t=0.000001068) than the previously recorded value (t=0.000001658).


t = 0.
000001658 is the old finishTime
t = 0.000001068 is the new finishTime

According to the stack-trace the error is thrown on the sendDelayed line above.
I played around with the delay for a bit, and the error disappears as soon at the delay pushes the start time >= the original finishTime.

Does someone know what's going on? Am I even using "result-recording-modes" correctly?

Till

unread,
Dec 3, 2015, 10:09:12 AM12/3/15
to OMNeT++ Users
I'm having the same problem.

documentation for cChannel::forceTransmissionFinishTime says:
This method is a crude device that allows for implementing aborting transmissions; it is not needed for normal packet transmissions. Calling this method with the current simulation time will allow you to immediately send another packet on the channel without the channel reporting error due to its being busy.

Problem is that the channelBusySignal for txfinishtime is already recorded when the transmission starts.

Am I missing a feature here, or is this a bug? I would expect that the channelBusySignal is emitted when the frame has finished the transmission. Otherwise aborting transmissions would be impossible.
A solution would be to store the last txfinishtime and emit it with the next processMessage(). This way the time at forceTransmissionFinishTime() would be taken into account.

comments highly appreciated!
Best regards
Till

Till

unread,
Dec 11, 2015, 8:49:21 AM12/11/15
to OMNeT++ Users
I opened a bug for this: https://dev.omnetpp.org/bugs/view.php?id=943 please consider patch for omnet 5.0

Best regards
Till
Reply all
Reply to author
Forward
0 new messages