Changes between Version 2 and Version 3 of Documentation/FAQ


Ignore:
Timestamp:
Sep 29, 2005, 8:55:21 PM (19 years ago)
Author:
max
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • Documentation/FAQ

    v2 v3  
    11[wiki:WikiStart Orbit] > FAQ
    22
    3 = FAQ =
     3{{{
     4#!rst
     5========
     6FAQ
     7========
    48
    5 Here you can find the answer to some of the most frequently asked questions about !NodeHandler. If you have a question not answered by this page you can ask it on the MailingList. 
     9Here you can find the answer to some of the most frequently asked questions about NodeHandler. If you have a question not answered by this page you can ask it on the `MailingList`:trac:. 
    610
    7 Questions answered in seperate pagess:
    8  * [wiki:NodeHandler/FAQ/HowToControlNodes How to control nodes?]
    9  * [wiki:NodeHandler/FAQ/ToCreateDebianPackage Which Tools are needed to create a debian package?]
    10  * [wiki:NodeHandler/FAQ/ToUseNoiseGenerator How to Use Noise Generator in experiments?]
    11  * [wiki:NodeHandler/FAQ/SandBoxConvention Sandbox IP convention?]
    12  * [wiki:NodeHandler/FAQ/ProgrammingNodeID How to Program a Node ID box?]
    13 
    14 == How to check the status of my experiment? ==
    15 
    16 Point your browser to http://remote.orbit-lab.org:4000/xml
    17 
    18 == How do I log into a node to see what is happening? ==
    19 
    20 From remote.orbit-lab.org, you can use the serial console access provided by CM as follows
    21 
    22         telnet 10.1.x.y 3025
    23 
    24 == How do I check the status of the imaging process? ==
    25 
    26 Point your browser to http://remote.orbit-lab.org:4000/progress
    27 
    28 == How to interpret the progress bar? ==
    29 
    30 INFO exp: Progress: 30/45/60 min/avg/max (84.571326)
    31  
    32 For the imaging process, this means that slowest node is 30% done and fastest node is 60% done
    33 The average might require an additional explanation.
    34 
    35 INFO exp: Progress: 90/85/100 min/avg/max (234.240859)
    36 
    37 The average is calculated as the progress over ALL nodes, while the min/max
    38 are for the nodes which have started frisbee already. In the above case, a
    39 few nodes hadn't booted up yet.
    40 
    41 == Where are the noise antennas located? ==
    42 
    43  * Antenna 1: Between node2-1 and node2-2
    44  * Antenna 2: Between node2-7 and node2-8
    45  * Antenna 3: Between node7-1 and node7-2
    46  * Antenna 4: Between node7-7 and node7-8.
    47 
    48 [Kishore]
    49 
    50 == Where can I find information about the wireless cards used in Orbit ==
    51 
    52 Please look at the madwifi driver for atheros cards, the ipw2200 driver
    53 for Intel cards and related documentation online. I believe the
    54 model no. for atheros cards is AR5212. [Kishore]
    55 
    56 == Which interface is which? ==
    57 
    58 For Atheros based nodes, ath1 is near the power supply, ath0 is near the serial port
    59 For Intel based nodes, eth3 is near the power supply, eth2 is near the serial port
    60 
    61 == It seems that Node[5,6] cannot receive any packet from Node[7,4] ==
    62 
    63 If you assign the netmask in the script to be 255.255.255.0 it filters out
    64 all nodes but something1.something2.somethin3.x. If you assign 255.255.0.0 all the nodes on the grid are on the same subnet. [Haris]
    65 
    66 == When I run 'ntpdate ntpservername' on a node, I got an error that the ntp port is used already. ==
    67 
    68 The nodes run ntpd as a service which occupies the port and hence you get the error when you try to manually run ntpdate. You could disable ntpd, run ntpdate manually and then enable ntpd again to overcome the slight drifts. [Sachin]
    69 
    70 == Interpreting error messages ==
    71 === Error message ===
    72 FATAL run: Exception: Can't switch off node ALL:ALL (#<Net::HTTPServerError:0xb7be7ce4>) RuntimeError
    73        /tmp/eee.972/lib/handler/cmc.rb:46:in `nodeOff'
    74 
    75 Fix: CMC service is not running (or dead), need to restart CMC service
    76 
    77 == Where can I find out more about the schema used in the Orbit database? ==
    78 Is this some thing I design myself for my own purposes or is there some
    79 previously designed schema that everybody uses?  How does one experiment
    80 code write stuff to the database, or does this happen automatically?
    81 
    82 ORBIT Services will create ONE database (same name as
    83 experiment ID) per experiment. However, the database may contain multiple tables. One for
    84 each application/configuration used in the experiment and - soon, but not
    85 yet - an experiment specific table containing all the experiment related
    86 information.
    87 
    88 Each application (in the definition file) tells nodehandler what is needs as
    89 inputs and what are the statistics it will report. Accordingly nodehandler instructs the oml grid service to create a table in the
    90 database with the appropriate schema.
     11The Orbit team is actively seeking new items to add to this list. If you would like to add an item, or have a suggestion on how to make this list more useful, please send us email at faq@orbit-lab.org.
    9112
    9213
    93 The database schema for the receiver side information is as follows
    94 Where rcvd_pkt_size_sample_sum = throughput
     14.. contents::
     15.. sectnum::
     16
     17-----
    9518
    9619
    97 || Field                    || Type        ||
    9820
    99 || node_id                  || varchar(32) ||
    100 || sequence_no              || int(11)     ||
    101 || timestamp                || int(11)     ||
    102 || stream_no                || int(11)     ||
    103 || pkt_seqno                || int(11)     ||
    104 || sender_port              || int(11)     ||
    105 || flow_no                  || int(11)     ||
    106 || pkt_num_rcvd             || int(11)     ||
    107 || rcvd_pkt_size_sample_sum || int(11)     ||
    108 || rx_timestamp             || int(11)     ||
    109 || rssi                     || int(11)     ||
    110 || xmitrate_sample_mean     || float       ||
     21
     22ORBIT Profile
     23=============
     24What types of experiments does ORBIT support?
     25---------------------------------------------
     26
     27The ORBIT radio grid emulator is an indoor wireless network testbed. It supports experimental research on a broad range of wireless networking issues and application concepts with various network topologies and network layer protocol options.  It also support virtual mobility for mobile network protocol and application research. The ORBIT radio grid emulator currently uses 802.11x based radio cards. Some examples of systems and protocol designs that can be investigated on the ORBIT emulator grid include:
     28
     29  * Large-scale wireless access networks based on 802.11a, b, g radios along with new protocols for discovery, routing, mobility management, security, etc. under various indoor and outdoor usage scenarios and network topologies.
     30  * Mobile ad hoc networks (MANET), typically based on 802.11x  radios, along with multi-hop ad hoc routing protocols such as AODV, DSR and new protocols.
     31  * Wireless sensor networks and pervasive computing applications.
     32  * Mobile applications such as location-based services, VoIP over MANET, mobile multicasting, etc.
     33
     34In the future, the ORBIT emulator grid will support other radio interfaces such as Blootooth and allow research on heterogenerous wireless networks. It can also accommodate new technologies such as UWB as they emerge.
     35         
     36Can I test my new physical layer model on ORBIT?
     37------------------------------------------------
     38
     39No. Due to indoor setup constrains, the ORBIT emulator grid does not capture all radio channel effects. The radio channels for the ORBIT emulator grid will normally have no significant multipath. For physical layer radio testing, the absence of multipath would be unacceptable; however, for a wireless network testbed, the differences are less significant.  A combination of channel impairment and multiuser interference results in the failure of the physical layer to provide a reliable link so that connectivity is lost at the network layer. Using programmable interference and grid mobility, the emulator will create similar variations in network connectivity.
     40
     41
     42Can I test my new 802.11 MAC scheduling scheme on ORBIT?
     43--------------------------------------------------------
     44
     45Yes and No. The ORBIT radio grid emulator currently uses standard 802.11x radio interface cards with Linux drivers (Host AP and MADwifi). The drivers allow changing certain parameters such as channel, TX power, TX rate, etc. but not all. If your new MAC scheme requires 802.11 modification that is not supported by our current drivers.  We also plan to develop more flexible drivers and customized 802.11x cards in collaboration with chip and card manufacturers
     46
     47How is the mobility supported by ORBIT?
     48---------------------------------------
     49
     50The ORBIT radio grid emulator support virtual mobility. Virtual mobiles are introduced for discretized grid mobility. Physically located off the radio grid, a virtual mobile has a network driver that delivers packets to a mobility controller. Via high speed wired Ethernet, the mobility controller encapsulates and forwards these packets to a radio grid node i, which simply decapsulates and transmits each packet.  In addition, packets received by grid node i will be forwarded via the mobility controller to the virtual mobile. In short, the virtual mobile will appear to be at grid location i by using radio grid node i for transmitting and receiving packets.  It will use grid radio node j when it "moves" to grid location j. Grid mobility can support discretized versions of commonly used mobility models such as Brownian motion or the random waypoint model. In addition to virtual grid mobility, we plan on a small number of programmable mobile robots. These mobiles will communicate with the radio grid and allow experimentation with finer grain mobility experiments.
     51
     52What radio parameters can I measure?
     53------------------------------------
     54
     55Currently, RSSI, TX_power, noise, throughput, and offered-load can be measured and collected. Users can select one or more of these parameters to be collected and stored in the database.
     56
     57Getting Started
     58===============
     59
     60Who is eligible to use ORBIT?
     61-----------------------------
     62
     63As ORBIT name (Open-Access Research Testbed for Next-Generation Wireless Networks) says, almost all research or educational uses by those that have a need for it are appropriate and encouraged. These include use by universities, industrial research labs, and both US and non-US institutions. With some provisions, use for product development and evaluation by companies is also acceptable. Please email us if you are interested.
     64
     65How do I start a project?
     66-------------------------
     67
     68ORBIT is still under development. Please email us if you are interested in doing experiments with the ORBIT testbed. In the future there will be a web interface for the project application.
     69
     70Using the ORBIT Testbed
     71=======================
     72Is there a tutorial?
     73--------------------
     74
     75Yes, it is available here.
     76
     77Do I get root access on my radio nodes?
     78---------------------------------------
     79           
     80Yes. you can get root access to all of the radio nodes used in your experiments.
     81
     82Do my nodes have consoles I can look at?
     83----------------------------------------
     84
     85Yes. Each of the radio nodes has its own serial console line with which you can interact through the chasis manager (CM). In any case, all console output from each node is saved so that you may look at it later.
     86
     87Can I reboot (power cycle) my nodes?
     88------------------------------------
     89
     90Yes. Each of the radio nodes is independently power controlled by the chasis manager. If your node hangs, or is otherwise unresponsive, you can reboort it.
     91
     92Are there Linux sources and packages available locally?
     93-------------------------------------------------------
     94
     95Yes. We provide sources and packages for a few versions of  Linux. We are also developing software components and libriaries for experiemnt control, experiment data collection, and user application development.
     96
     97Hardware Setup
     98==============
     99How many radio nodes are there?
     100-------------------------------
     101
     102Currently, we will support 64 nodes in a 8*8 grid. In the near future, this will be increased to 400 nodes in a 20*20 grid
     103
     104How many radio interfaces on each node?
     105---------------------------------------
     106
     107There are two mini-PCI 802.11 a/b/g interfaces cards on each node. In addition to that, there will be USB-based Bluetooth and Zygbee interfaces.
     108
     109What OS do the nodes run?
     110-------------------------           
     111The default Operating Systems that run on each of the radio nodes is Linux (Debian GNU/Linux 3.0 with Linux kernel 2.6.4). But every experimenter can load any OS they want.
     112
     113Can I run my own Operating System?
     114----------------------------------
     115
     116Yes, you can run your own OS (or a customized version of an ORBIT-supported OS) on any of the radio nodes. We provide infrastructure to image the nodes involved in the experiment with the provided OS image.
     117
     118Can I load my own software packages on my nodes?
     119------------------------------------------------
     120
     121Yes! If have one or more software packages that are appropriate for loading on the OS you have selected, you can arrange to have them loaded automatically via APT package system when your experiment is configured. You may specify a different list of software packages for each radio node in the experiment. When the node first boots after the experiment is configured, each of the packages will be installed.
     122
     123Is the ORBIT testbed firewalled?
     124--------------------------------
     125
     126Yes.
     127
     128Tips
     129====
     130
     131Some interesting observations regarding wireless cards
     132------------------------------------------------------
     133
     134A few interesting things for wireless experimenters in general
     135  * Some cards do allow you to set certain transmit power values even though they are not supported by the hardware. E.g Cisco Aironet 350 series card supports 1, 5, 20, 30, 50 and 100 mW transmit powers. However, it does not complain even if the transmit power is set to other values. We believe that it is simply rounded off to the next allowable power level
     136  * Not all cards allow you to change the channel. On the Cisco Aironet 350 series card, in order to change the channel, you have to create a new essid and then switch to the new channel.
     137
    111138
    112139
    113140 
     141}}}