Bugzilla – Bug 411
OnOffApplication::OnTime does not work
Last modified: 2008-12-09 15:26:43 EDT
You need to log in before you can comment on or make changes to this bug.
this is reported by an ns-3 user here: http://groups.google.com/group/ns-3-users/browse_thread/thread/9cb963b9fdd1ce36 I verified this using the simple-point-to-point-olsr script and configuring the attribute as stated in the message. Looking at the code, the problem is that: void OnOffApplication::ScheduleStopEvent() is never called.
the problem does not seem to be related to the OnTime attribute: I can see that _no_one_ ever calls ScheduleStopEvent so, I have no idea what is the purpose of the m_onTime variable. Raj, I assume that this bit of the code is coming from gtnets: is it true ? If so, do you have any idea of what was the purpose of that variable and how it was expected to be used by the on off application implementation ? Since this specific attribute is widely used, we really should fix this bug. Priority is P1.
The expected behavior is this: The application comes "on" for some time, during which in sends data. This amount of time is drawn from a random variable distribution. It then goes "off" for some time, during which it sends no data. This amount of time is drawn from _another_ random variable distribution. The current OnOff application appears then to be broken, since it never turns off. Oddly, it appears to have been always broken, from the initial check in.
Created an attachment (id=323) [details] Fixes the onoff app Makes the app actually turn off and on.
Created an attachment (id=324) [details] test case show OnTime and OffTime both work You can change the on and off times and watch the "duty cycle" of the burst/onoff behavior change as you would expect. If you use octave, the following script will generate a nice picture of the packet sizes plotted against their timestamps. #!/bin/bash tcpdump -r simple-udp-0-0.pcap -nn -tt | cut -d" " -f 1,8 > temp.out echo "x=load temp.out; plot(x(:,1),x(:,2),'o'); print('plot.eps');" | octave
Can you please look at each example script (including any not in the regression script) and provide a second patch? This patch makes at least one of them (csma-bridge) run unbounded.
Created an attachment (id=328) [details] fix which doesn't "leak" events outside of simulation time This makes the regression suite flip out. I am verifying the changes to the traces are what we expect them to be.
As far as I can tell, the changes to the regression output are expected given that the "residual bits" are being calculated for during the off time. Since there was to offtime before... Still checking though. I think this needs to cook a little longer.
(In reply to comment #7) > As far as I can tell, the changes to the regression output are expected given > that the "residual bits" are being calculated for during the off time. Since > there was to offtime before... > > Still checking though. I think this needs to cook a little longer. > I'm asking Craig to review and try to merge it today.
Applied by Craig 3996:2277ff80158c