OTG FAQ
Here you can find the answer to some of the most frequently asked questions about OTG.
General
What is OTG?
OTG is a software package which contains at least two executable programs in Unix/Linux environment: otg and otr.
Is OTG free software?
OTG is open-source software and could be downloaded by everyone. However, by default, OTG/OTR are supposed to be used in ORBIT testbed to take advantage of Orbit measurement framework.
How can I install it?
The installation of Orbit Traffic Generator is simple. On any node of Orbit Testbed, give command
apt-get install otg
three binary files "otg" "otr", "otf" will be copied to /usr/local/bin directory.
Where do I get the source code?
For orbit developers, latest sourcecode of OTG software can be checked out by this command
svn co http://svn.orbit-lab.org/svn/orbit/otg/trunk otg
Where can I find documentation of OTG/OTR?
Simply saying, this FAQ and the User Manual is enough for ordinary users. For developer, the Architecture design document and the function specifications would be important descriptive sources for understanding the whole design.
If you want a real detailed documentation of code, it can be generated by the Doxygen tool
cd otg/doc/ doxygen otgdoc.cfg
Note: If Doxygen generates contradictory descriptions against Function Specification, Function Specifications take precedence.
What is OTF?
OTF is the Orbit Traffic Forwarder. It is designed in order to enable layer-2 packet forwarding by MAC address. It could be used as a means to avoid routing protocols.
Using OTG with NodeHandler
Why I have to write nodeHandler scripts to use OTG?
Basically, NodeHandler is a comprehensive tool to control the whole experiment in Orbit Testbed, including the functions to power on/off nodes, setup/break wired/wireless links. As OTG software can be used to test a link only after the link is eatablished, it is not a bad idea to use "nodehandler" to give command-line and run-time options for OTG/OTR program too. Therefore, the nodehandler script will include all necessary information to start, stop and control OTG programs. Users will no longer need to input command line arguments manually. What's more, with this, users do not need to SSH to every node and run the OTG program one by one manually if an experiment involves a large number of nodes.
When using nodehandler, where can I find the outputs of OTG/OTR during the experiment?
It is the experiment log, which is put in /tmp directory of console and named with your expeiment-id.log.
Some stdout output of otg/otr could be found:
2005-09-22 16:58:54 DEBUG nodeHandler::comm: process message (0): '/r_1/c_2 3 APP_EVENT STDOUT app:otg "packet size parameter is set as 1024"}' 2005-09-22 16:58:54 DEBUG nodeHandler::NodeHandler: Process message '/r_1/c_2 3 APP_EVENT STDOUT app:otg packet size parameter is set as 1024' 2005-09-22 16:58:54 DEBUG nodeHandler::agentCmd::APP_EVENT: STDOUT' from 'app:otg' executing on n_1_2: 'packet size parameter is set as 1024' 2005-09-22 16:58:54 DEBUG nodeHandler::node::n_1_2: Message for app 'app:otg' 2005-09-22 16:58:54 DEBUG nodeHandler::comm: process message (2): '/r_1/c_2 4 APP_EVENT STDOUT app:otg "Destination Hostname: 192.168.1.4"}' 2005-09-22 16:58:54 DEBUG nodeHandler::NodeHandler: Process message '/r_1/c_2 4 APP_EVENT STDOUT app:otg Destination Hostname: 192.168.1.4' 2005-09-22 16:58:54 DEBUG nodeHandler::agentCmd::APP_EVENT: STDOUT' from 'app:otg' executing on n_1_2: 'Destination Hostname: 192.168.1.4' 2005-09-22 16:58:54 DEBUG nodeHandler::node::n_1_2: Message for app 'app:otg' 2005-09-22 16:58:54 DEBUG nodeHandler::comm: process message (2): '/r_1/c_2 5 APP_EVENT STDOUT app:otg "Rate is set as 300000bps"}' 2005-09-22 16:58:54 DEBUG nodeHandler::NodeHandler: Process message '/r_1/c_2 5 APP_EVENT STDOUT app:otg Rate is set as 300000bps' 2005-09-22 16:58:54 DEBUG nodeHandler::agentCmd::APP_EVENT: STDOUT' from 'app:otg' executing on n_1_2: 'Rate is set as 300000bps' .... 2005-09-22 16:58:54 DEBUG nodeHandler::node::n_1_1: Message for app 'app:otr' 2005-09-22 16:58:54 DEBUG nodeHandler::comm: process message (0): '/r_1/c_1 4 APP_EVENT STDOUT app:otr "binding to port: 4000......"}' 2005-09-22 16:58:54 DEBUG nodeHandler::NodeHandler: Process message '/r_1/c_1 4 APP_EVENT STDOUT app:otr binding to port: 4000......' 2005-09-22 16:58:54 DEBUG nodeHandler::agentCmd::APP_EVENT: STDOUT' from 'app:otr' executing on n_1_1: 'binding to port: 4000......'
Where can I see the experiment XML files ?
It is generated dynamically and put in the /tmp directory of the console. The naming convention for this file is "experimentname+timestamp". The oml_experiment XML files are stored in /tmp directory of the nodes participating the experiment. For example, if a node is running OTG during the experiment, an XML configuration file, which tells OTG where to send OML measuremeents, should be existing in the /tmp/ directory of that node. The name of that file consists of some random characters.
Writing Scripts for OTG Application
I need to specify the OTG sender port in the experiment file, what all do I need to modify?
you can check if the otg.rb already list "port" as a property or not? If yes, then go to sender.rb to see if the "port" property is bind to the sender object or not? if both are done, you can configure this property as same as other property in your experiment script.
Trouble shouting
why the OML database for my experiment has empty tables (0 records)?
The OTG/OTR is only used to test link performance. The user has to ensure the link availability before running OTG/OTR programs. One plausible reason for empty table is the link does not exists at all (wrong channel setting, cell id mismatch…). This is surprisingly frequent in wireless tests. Check your experiment scripts carefully.
Why I get "bind error" when starting otg/otr?
Be sure a port in one machine can only used by one program. If you run multiple OTG programs in one machine, use different "—port" settings.
Why during the experiment, OTG offerload suddenly drops to zero, till the end of experiment?
The problem is that the sender failed to continue sending any packets out due to a driver issue. It often happened when sender tries to push offered load which is higher than the actual wireless link capacity. This problem is usually seen in Atheros card.
Why OTG is not sending out any packets (checked by tcpdump) while running?
Be sure that the sending node's IP routing table does have a route entry to the destination. Otherwise, the packets generated will be queued in sender's buffer and no way out.
