BlogJava-伊落丹矩阵_Reservation-随笔分类-Network Simulators http://www.blogjava.net/illidan/category/38684.htmlWLAN, 3GPP, Wireless Meshzh-cnMon, 30 Mar 2009 12:26:36 GMTMon, 30 Mar 2009 12:26:36 GMT60Monash.Univ::OMNeT++ vs. ns-2http://www.blogjava.net/illidan/archive/2009/03/30/262914.html伊落丹伊落丹Mon, 30 Mar 2009 08:29:00 GMThttp://www.blogjava.net/illidan/archive/2009/03/30/262914.htmlhttp://www.blogjava.net/illidan/comments/262914.htmlhttp://www.blogjava.net/illidan/archive/2009/03/30/262914.html#Feedback0http://www.blogjava.net/illidan/comments/commentRss/262914.htmlhttp://www.blogjava.net/illidan/services/trackbacks/262914.html


. OMNeT++ ns-2
Flexibility OMNeT++ is a flexible and generic simulation framework. One can simulate anything that can be mapped to active components that communicate by passing messages. For example, it can be used for simulating queueing networks, multiprocessor systems, hardware architectures (routers, optical switches, file servers etc.), or business processes. Several model frameworks available for different problem domains (INET Fw, Mobility Fw, OverSim, NesCT, MACSimulator, etc.) ns-2 has been designed as a (TCP/IP) network simulator, and it difficult to impossible to simulate things other than packet-switching networks and protocols with it. It has highly detailed and hardcoded concepts about nodes, agents, protocols, links, packet representation, and network adresses etc, which is good, but makes it very hard if you want to do things a little differently.
Programming Model Object-oriented, event-driven simulator, written in C++. Topology descriptions are either written as text files (NED language), or can be dynamically created in run-time. There is also a graphical interface (GNED) for creating and editing the topologies, which automatically creates the topology file. Mixed-mode: OTcl (Object-Tcl) with underlying C++ classes. OTcl is also used for creating and configuring networks, recording results etc.
Model Management The OMNeT++ simulation kernel is a class library, i.e., models in OMNeT++ are independent of the simulation kernel. The researcher writes their components (simple modules) against the OMNeT++ simulation kernel API. OMNeT++ sources are never patched by models. Simple modules are then reusable, and can be freely combined like LEGO blocks to create simulations,. In ns-2, boundary between simulation core and models is blurred, without a clear API. Install instructions for 3rd party models usually begin like: "download ns2 2.xx.x, unpack it, then apply the following patch..."
Support for Hierarchical Models Hierarchical module structure in OMNeT++ facilitates dealing with complexity in a methodical manner. Model designer assembles a complex model from self-contained building blocks (i.e. simple modules and compound modules) which are resuable in other simulations as they are. In ns-2, models are "flat": creating subnetworks, or implementing a complex protocol as a composition of several independent units (that appear as one unit) are not possible in ns-2.
Debugging and Tracing Support OMNeT++ can show packet transmissions while a simulation is running. OMNeT++'s Tkenv is an interactive execution environment, which allows one to examine the progress of simulation and change parameters. There is also extensive library support for packet tracing etc. ?
Variety of Models Available OMNeT++ has a good variety of models for simulating computer systems, queueing systems etc., but lags behind the ns-2 simulator on availability of communication protocol models. ns-2 has a rich set of communication protocol models (since it has been designed as a network protocol simulator, this is not surprising).
Documentation OMNeT++ has a well written and up-to-date manual (there are also tutorials for quick introduction). OMNeT++'s simulation API is more mature and much more powerful than ns-2's. ns-2 documentation is fragmented (there is a good tutorial for quick introduction). There is no clear dividing line between the models and the ns-2 simulation library.
Ability to Run Large Networks OMNeT++ can simulate very large scale network topologies. The limit is the virtual memory capacity of the computer used. ns-2 has scalability problems on simulating large network topologies (more details needed here).
Support for Parallel Simulation Supports conservative parallel distributed simulation. The Null Message Algorithm (Chandy-Misra-Bryant) and Ideal Simulation Protocol (Bagrodia et al) are supported; others can be plugged in. Lookahead models for NMA can be plugged in. Communication layer is pluggable: currently implemented ones are MPI, named pipe, and file-based (for debugging). Unlike PADS, models do not need to be modified or instrumented for parallel simulation -- it is just a matter of configuration. The PADS research group at Georgia Tech. has developed extensions and enhancements to the ns-2 to allow a network simulation to be run in a parallel and distributed fashion on a network of workstations.
Experiment Design Parameters of a simulation experiments are written in the omnetpp.ini, which enforces the concept of separating model from experiments. Models and experiments are usually interwoven in ns-2: topology, parameters, model customizations, result collection etc usually in the same Tcl script, which makes "separation of concerns" difficult.
Embeddability OMNeT++ simulation kernel can be embedded in other applications (where one can use alternative means of intpu/output, e.g., use databases). The existing user interfaces can be extended via plug-ins, modified or replaced. ?


http://ctieware.eng.monash.edu.au/twiki/bin/view/Simulation/OMNeTppComparison



伊落丹 2009-03-30 16:29 发表评论
]]>SEACORN::网络仿真器比较http://www.blogjava.net/illidan/archive/2009/03/30/262886.html伊落丹伊落丹Mon, 30 Mar 2009 06:54:00 GMThttp://www.blogjava.net/illidan/archive/2009/03/30/262886.htmlhttp://www.blogjava.net/illidan/comments/262886.htmlhttp://www.blogjava.net/illidan/archive/2009/03/30/262886.html#Feedback0http://www.blogjava.net/illidan/comments/commentRss/262886.htmlhttp://www.blogjava.net/illidan/services/trackbacks/262886.html
The objective is to reuse any suitable software, or selection of software, that is well acknowledged and tested. The selection of the software tool (s) to be used in the project will be decided in the beginning of the project by the consortium members.

Validation and assessment is a hard 'nut to crack' even for existing, widely used (integrated) commercial and non-commercial simulation tools. The complexity of the protocols and the level of abstraction required are such that make it a very difficult task. The experience of the partners, for example with OPNET and with ns2 (also evidenced through discussion lists) bring to light the fact that even well tested simulation software can still have 'bugs' for the seemingly well tested TCP/IP protocol suite (IPv4), either due to the code or the protocol interpretation. (A recent study has identified more than 400 different implementations and versions of the TCP/IP stack). The tradeoffs between simulation tractability and oversimplification of results is not an easy task. Striking the right balance between the fundamental underlying dynamics in packet behaviour in the Enhanced UMTS environment and specific performance in particular environments and specific protocols in a future scenario is by no means an easy task.

A recent paper by Sally Floyd and Vern Paxon, 'Difficulties in Simulating the Internet', IEEE/ACM transactions in Networking, Vol. 9, No. 4, August 2001, highlights above difficulties. In the abstract it is clearly stated that simulating how the global Internet (a live, running network) behaves is an extremely challenging undertaking because of the network's great heterogeneity and rapid change. One of the biggest problems in simulating the Internet is the lack of typical 'operational' data or traces (the Internet traffic has proven to be rapidly evolving and dynamic), which can be used to validate the simulator behaviour. This is expected to worsen, as the current networking paradigm is expected to be different from a future networking environment, based on high speed wired and wireless access (especially for Enhanced UMTS), supported by a new set of protocols and a rich set of (new) applications. Measurement and experimentation with current Internet traffic have limitations; they can possibly be used to explore particular new environments, but not new architectures and applications for the future Internet. Adding mobility and high-speed wireless networking increases the complexity further since radio propagation and node mobility are difficult and expensive to model, and lack of experience with networking scenario in such networks.

Another recent paper, by J. Heidemann, K. Mills, S. Kumar, 'Expanding Confidence in Network Simulations', IEEE Networks, September/October 2001, discusses best practices for validating simulations and for validating TCP models across various simulation environments. Despite the almost universal use of simulation to predict performance of complex networks, and to understand the behavior of existing and the correctness and performance of new protocol designs, there are no widely accepted practices and techniques to help validate network simulations and to evaluate the trustworthiness of their results. Validation is the process of assuring that a model provides meaningful, trustworthy, answers to the questions being investigated, in accordance with real world behavior. As models often involve approximations or abstractions from reality, validation provides confidence that these approximations do not substantially alter the answers to the questions being posed. Furthermore, different situations require different levels of validation; the level of validation required for a network simulation is influenced by the questions being asked and by the systems being used. The paper discusses issues (and difficulties) that need to be considered when validating network simulations. These include:
  • Establishment of 'ground truth' and comparison with simulator results with direct comparison with reality, whenever possible.
  • Clarity of specifications vs implementation. Some protocol parameter settings (e.g. window size) may affect performance substantially (e.g. steady state throughput changes by a factor of 2-10 has been reported).
  • Comparing simulations as protocol designs evolve. As the Internet is dynamic and protocol designs evolve, care must be exercised when comparing specific implementations and in the way general conclusions are drawn.
  • Comparing simulations as network traffic changes. Validation against yesterdays or today's traffic mix, may not have much to do with the future networking traffic patterns and scenarios.
  • Choosing appropriate metrics for comparisons. Given the 'ground truth' metrics must be derived to compare simulation results against the truth. Evaluating against the full real world behavior is not practical, thus often specific aspects are evaluated. Generalising from the specifics is still an open research question.
  • Evaluating the sensitivity of simulations. Once validation has been performed under one set of conditions, sensitivity analysis helps understand how varying configurations change the accuracy of the simulation.
  • Large scale simulation and validation. Two complimentary approaches to large scale simulation are widely adopted: parallel executions and abstraction. Also hierarchical (recursive) composition, build from well-validated components, and a well validated framework can be usefully employed.
  • Incorporating mathematical models as subsystems in discrete event simulations can greatly help.
  • Assessing cost-benefit tradeoffs. The extent, and therefore the cost of validation must be considered against the likely benefits.

For validation and assessment, in SEACORN we plan to include a selection of complimentary approaches, as for example:
  • Clearly and explicitly document the assumptions, abstractions, and limitations.
  • Identify the dependencies between any assumptions and simplifications, thus allowing for the error to be controlled and taken into account.
  • Identify and explore the dangers and pitfalls in modelling and simulating Enhanced UMTS.
  • Whenever possible, complement and compare simulation results with models, analysis, measurements, and experiments keeping in mind the limitations of each method.
  • Review of existing literature on methodologies and best practices with regard to validation and assessment.
  • Define metrics and criteria for assessing and validating the simulation software.
  • Construct confidence intervals so that the reliability of the simulation results can be identified.
  • Design in as many means as possible for examining the state of simulation (including animations where practicable).
  • Identifying any behaviour that has been shown empirically to hold in a very wide range of environments (Invariants in behaviour) and backing these with a sound theoretical analysis. Caution will be exercised as to the validity of the 'invariant' in a future networking scenario in Enhanced UMTS. Development of heuristics for evaluation of Enhanced UMTS network performance.
  • Identify and explore a representative parameter space (sensitivity analysis) of behaviour.
  • Design validation tests that will include standards tests and run these validation tests regularly, including for each simulator release.
  • Use reference scenarios, as for example those defined by 3GPP in TR25.942 and TR101.112.
  • Ensure that simulation results are reproducible. Care is required in generating pseudo-random numbers sequences, mitigation of rounding due to floating point representation errors, which may affect event concurrency (especially when using parallel simulation).
  • Make simulation scripts and simulation scenario publicly available, so that other researchers can easily check for themselves (and validate) the effect of changing network conditions and assumptions.


http://seacorn.ptinovacao.pt/sim_tools.html



伊落丹 2009-03-30 14:54 发表评论
]]>