A Small ORBIT Tutorial

Zhibin Wu (June 2005)

Contents:

1. Obtain an ORBIT account
2. Reservation ORBIT slot
3. Control the nodes in the grid
4. Loading an image to orbit nodes
5. Saving a node image
6. Prepare experiment script
7. Run an experiment
8. View the experiment result
9. Understanding measurement metrics

Advanced Topics:

1. Nominal load and offered load
2. Blocking socket and non-blocking socket
3. RSSI reporting is independent of noise values
4. RSSI reporting deviations depends on the packet interval

Obtain an ORBIT account

Send an email to Faiyaz (faiyaz@winlab.rutgets.edu), describe briefly about your purpose of using the Testbed, and mention that whom you are working for. Please ask Faiyaz to create an ORBIT account for you. Also, ask Faiyaz to add your email address to ORBIT-USER list.

Reservation of ORBIT slot

After you get orbit account, you have to reserve a time slot for your practices and experiments. (log in to www.orbit-lab.org... and select the "reservations" menu in the left menu list). Then viewing the grid schedule page and reserve.


The maximal allowed slot reservation is 4 hours per day.

Control nodes in the grid

There are two ways to control the node. Web interface and Console interface

• Web Interface. Go to http:// internal1.orbit-lab.org, be familiar with the content of pages and using buttons to power on an off the nodes...( assuming you are using a winlab machine. or through VPN....)

  

• Log in to cosole.grid and telnet the nodes if you have no access to Web interface
   

  ssh username@console.grid.orbit-lab.org telnet 10.1.x.y %(x,y) are coordinates of the node help power on power off

  note: a user can only access console.grid at his or her reserved time slot.

Loading an image to orbit nodes

ssh username@console.grid
cd /opt/nodeAgent3/src/ruby
ruby nodeHandler.rb system:exp:imageNode -- --nodes [[4,3],[5,4]] --image baseline.ndz

Open a browser to "http://console.grid.orbit-lab.org:4000/xml"  to view the progress.
Remember: you don't  need to power on nodes before imaging. The nodes will be on automatically and will be off after the imaging finished.
Try to load other nodes by using different coordinates,  practice this several times.

Saving a node image

ssh username@console.grid
cd /opt/nodeAgent3/src/ruby
ruby nodeHandler.rb system:exp:saveNode -- --node [7,7]

The name of your saved image will be like "node-7-7-2005-03-08-12-55-34.ndz". To reload your saved image to several nodes, you can do:

ruby nodeHandler.rb system:exp:imageNode -- --nodes [[4,3],[5,4]] --image tmp/node-7-7-2005-03-08-12-55-34.ndz

note: all images are now stored in repository2:/export/orbit/image directory

Understanding measurement metrics

 The following measurements are reported from OTG application to the local OML client in the node in the following order:

• stream_no: id of the stream

• pkt_seqno: Packet sequence id of the stream

• pkt_size: Payload size

• gen_timestamp: Deliver time the generator specifies

• tx_timestamp"Time when packet is being sent

There are nine metrics of measurements are reported from OTR application to the local OML client in the node in the following order:

• stream_no: id of the stream

• pkt_seqno: Packet sequence id of the stream

• sender_port: Sender port of the stream

• flow_no: id of the flow

• pkt_num_rcvd : Number of Packets received for this flow  identified by flow sequence id

• rcvd_packet_size: Received Payload size

• rx_timestamp: Time when packet is being received

• rssi: received signal strength indicator

• xmit_rate: Xmit rate indicated in the Signal Field of PLCP header of received packet. for example 55 indicates 5.5Mbps, 540 indicates 54Mbps.

Note that Stream and Flow are two different concepts.
Stream is used by OTG if OTG is configured to supply multiple streams rather than running multiple OTGs. The stream_no and pkt_seqno could reported by the OTR because those two parameters are piggybacked in the payload of the packet.
Flow is perceived from the OTR and classified by sender's IP address and port number. flow_no parameter will indicate the flow id of the packet. To corresponding the flow id with OTG instance (sender), you have to refer to sender_port parameter. You might need to configure every OTG sender in the Testbed with different port # to help you distinguish flows.
 

Advanced Discussions

Nominal load and offered load

When we testing a network link, we expect the traffic are really transmitted( at least attempted by the network device to deliver to. Only in this case, the "load" is meaningful. Unfortunately, when the generated traffic amount by the application ( denoted as N ) is larger than the actual bandwidth (capacity) (denoted as B) of a link, the packets will be dropped in tail of the buffer queue. So, what should be reported as "Offered load" in case N > B  ? In this case, we prefer to report a real value

we are using blocking socket to sending traffic based on following reasons:
1. each otg stream is created as a separate thread, therefore blocking in
one socket is not interfere with another
2. if a non-blocking socket is used, the call for send will immediately
return no matter what happened, it is acting like a 'polling'. In that case,
OTG will report only a "nominal' load which is always as same as what the
user specifies. By using blocking socket, the OTG could report a
"transmitted load" which is probably different from the "nominal load" when
the channel is not good.
In that case, users can calculate PER based on the equation of
"throughput/transmitted_load" instead of wrong "throughput/nominal_load".

 

RSSI reporting is independent of noise values

Surprisingly, the RSSI value reported by the Intel driver does not change correspondingly with increased noise injection in the testbed.