Bugzilla – Bug 388
document how to apply fuzz to models
Last modified: 2009-04-03 11:42:56 EDT
You need to log in before you can comment on or make changes to this bug.
I agreed to document an idiom on how to apply fuzz where needed. From Craig's writeup of WONTFIX bug 255: Consider: - Two applications are started at precisely t seconds; - Applications generate packets that require arp at precisely the same time; - LOOP: - Both arp protocols schedule retransmission for precisely t+timeout seconds; - Generated arp packets are sent at precisely t seconds; - Device/channel mechanism causes arp packets to collide and be discarded; - At t+timeout seconds, arp protocols retry on both nodes (at precisely the same simulation time); - t = t+timeout; - goto LOOP. The result is that ARP retransmissions happen at precisely the same time and collide over and over again. Our models may be "too deterministic" in some cases. Should models such as arp be configurable to add a random "fuzz" to their timeouts to simulate real timing uncertainties?
Testing email hook (bug touch)--- please ignore
another test of email hook-please ignore
How about implementing the following trivial API ? class ApplicationContainer { public: void Start (RandomVariable &v); }; app.Start (UniformVariable (0.9, 1.1)); There are lots of refinements which could be done on top of this basic idea but it seems to me that this would solve a lot of the use-cases we discussed in the past.
(In reply to comment #3) > How about implementing the following trivial API ? > > class ApplicationContainer > { > public: > void Start (RandomVariable &v); > }; > > app.Start (UniformVariable (0.9, 1.1)); > > There are lots of refinements which could be done on top of this basic idea but > it seems to me that this would solve a lot of the use-cases we discussed in the > past. > This is probably too limiting: - more than "start time" is needed (mainly, timeouts) - more than applications need to be covered (e.g. devices, operating systems, etc.) I was thinking, maybe move timer.cc,h to src/core and add Timer::SetFuzz (RandomVariable var); plus, a documented suggestion for users to know how to insert fuzz time between function calls, such as e.g. Simulator::Schedule (UniformVariable::GetSingleValue (), &function, this, arg1, arg2, ...); (or whatever UniformVariable::GetSingleValue () equivalent is with the new random variable API). Application::Start () and application containers could have starting time fuzz too, like you suggest.
(In reply to comment #4) > I was thinking, maybe move timer.cc,h to src/core and add > > Timer::SetFuzz (RandomVariable var); you can't move it to core because it depends on the simulator API and core does not depend on simulator: it is the other way around. > > plus, a documented suggestion for users to know how to insert fuzz time between > function calls, such as e.g. > Simulator::Schedule (UniformVariable::GetSingleValue (), > &function, this, arg1, arg2, ...); ok. > > (or whatever UniformVariable::GetSingleValue () equivalent is with the new > random variable API). > > Application::Start () and application containers could have starting time fuzz > too, like you suggest. My point, though, is that most other timers are synchronized on the first data packet going down the stack due to some implementation details so, if you do the application-level fuzz, you will get 90% of the solution in the current codebase. i.e., it's a cheap way to make decent progress.