Monday, November 27, 2006

Getting Started With QualNet

QualNet is a commercial network simulator produced by Scalable Network Technologies, Inc. It is a commercialized version of GloMoSim, but it is completely C-based, so it does not use GloMoSim's specialized "ParSec" language. QualNet includes a graphical "scenario creator" tool, but it's often easier to simply specify qualnet configuration files by hand, and it's certainly much faster, once you're familiar with the parameters.

Presentation from Spring 2007
Installing in Linux

I'll assume that you've gotten the Qualnet tarball from somewhere. Put it somewhere (for example, your home directory on your research lab's computing machine that has a license for QualNet available). Unroll the file using: tar -xzf qualnet.tgz (or whatever it's called)

You need to set a few environment variables, and update your path:

export QUALNET_HOME=~/qualnet/3.9.5 (assuming you unzipped the tarball in your home directory)


You should add these statements to your .bash_profile so you don't have to type them every time you log back in.

Next, you have to compile the application. This is easy. From the documentation:

For a machine running gcc 3.2 and higher:


cp Makefile-linux-glibc-2.3-gcc-3.2 Makefile


It will chug away. When it's done, you're ready to run qualnet.

Finally, copy the license file to $QUALNET_HOME/license_dir

To test that it works:


qualnet default.config

Some numbers should fly by.

Getting up and running with QualNet is fairly easy. A basic simulation is run simply by creating a number of configuration files. The configuration files are declarative, rather than script-based. You simply set up a scenario by defining a bunch of variables, and then let it rip using the command:

qualnet <name>.config

The best documentation for these files is in the qualnet installation. Look in qualnet/3.9.5/bin, and you will see a bunch of files using the naming scheme default.* (for example, default.config, default.nodes). These files are well-commented, and will serve as a good guide, and starting point.

For a basic simulation, you'll probably want at least these files:

* .config
* .nodes
* .app

Note that you can actually call these files ANYTHING you want, but these conventions make it easy to remember which files do what.

There are a HUGE number of other configuration files, controlling things like background traffic, antenna models, weather, link faults, and so on. If you want more info on these, check out the files in the directory! They are well-commented.
Configuration Files

This is the core QualNet scenario configuration. Let's look at some of the core configuration parameters in this files. This document will only cover BASIC configuration parameters for running a simple wireless experiment. You should copy the default.config file, because most of the default parameters for MAC/PHY settings in this file are good for beginning. If you want to modify them later, you can view comments in the file for more information.


This one should be straightforward enough. Call it whatever you want.


This specifies how long the simulation should run. The default.config file explains the different time values that can be used. For example, 15M = 15 minutes, 100S = 100 seconds.

* SEED <number>

A random seed for experiment repeatability.


Self-explanatory. Others exist, but this is probably what you want, as a beginner.


Sets the size of the terrain. X and Y are in meters.

* SUBNET N<subnet-specs> { node names }

This option is fairly complicated. For the early simulations, you probably want to have a single subnet of nodes, and the interface addresses the same as the node ID. To acheive that, for say, 10 nodes, use:
@@SUBNET N16-0 { 1 thru 10 }

* LINK N<subnet-specs> { node A, node B}

Create a *wired* link between two nodes. This complicates the setup a bit, so if you need wired links, examine default.config file for more details.


Describe how nodes are placed in the simulation terrain.

* GRID-UNIT <num>

Grid spacing if GRID placement is used.


Usually name.nodes, see below for description of the file.


Group mobility is an advanced option, we'll ignore it for now. If FILE is specified, then NODE-POSITION-FILE is used.


Specify how fine-grained movement steps should be.


Specifies which protocol should be used in this simulation. AODV or DSR, for example, or one you create yourself.

* APP-CONFIG-FILE <filename>

This specifies the file that contains the applications to be run in your scenario

* Statistics

You want to collect information from your simulation of course! There are quite a few options. You can pick and choose which traces and statistics you want to output when you run your simulation. Look for "HOST-STATISTICS" in the default.config file to see what your options are. Look for "PACKET-TRACE" in the file for more info about tracing. A nice feature of QualNet is that it will output quite a few basic statistics without requiring you to save or parse huge traces.

This file specifies node position, and mobility if used. The file is very straightforward, it is simply a series of lines of the form:

<node> <time> (<x>,<y>,<z>) <theta,phi>

For basic 2D experiments, you can set z to zero, and omit theta and phi.

The entries must be sorted in increasing time order. The simulator will do linear interpolations between two points in time.
<name> .app

This file specifies the applications to run. It is of the form:

<appname> <params>

The parameters will vary depending on the application. All of the apps and paramters for them are described in A basic option is CBR (constant bit rate). It is:

CBR <src> <dest> <items to send> <item size> <interval> <start> <end>

If <items to send>=0, the CBR client will simply send for the whole specified time interval.

CBR 1 2 0 512 1 10 1000

Send 512 byte packets from node 1 to 2 ever second for 990 seconds, starting at 10 seconds into the sim.

Thursday, August 10, 2006

Palm OS Flaws

I've been using the PalmOS since about 1999. It's amazing how much it's stayed the same in the past 7 years. In some ways, this is a good thing. Conceptually, PalmOS is very well designed for the target device. For its original PIM tasks, it's quite well designed. But 7 years later, I expect to see notable improvements, and I just haven't. So here's the run down, in no particular order:

1. The UI appearance is outdated. Many people will argue that this is irrelevant. These are the people that use TWM and Ratpoison as Window Managers in Linux. I whole-heartedly disagree that a nice, pleasant appearance is not an important part of a computing experience. It is possible to make something aesthetically pleasing without hurting performance. It was one thing when the Palm screens had a 2-bit depth, but with 16-bit color, I really expect a bit more.

2. Unevolved PIM features. Is this a business move, so that companies like DateBk? or Iambic can stay in business? The Palm PIM features have not changed _at all_, for the most part. Functionality like hierarchy in Todo Lists, linking of items, and better per-diem planning should be *integrated parts* of the system.

3. A horribly crappy syncing system. At one point, this was OK. When my palm connected via serial port, the behavior was more understandable. But now, 7 years later, they still essentially simulate that same protocol over a USB port. The whole point of USB is to make devices smarter, and allow the computer to automatically detect them. It is INEXCUSABLE that I still have to press a button on my palm in order to sync it. Really, people. Come on. Furthermore, network syncs simply don't work. The protocol is closed source, so Linux support is slow to come, and buggy. The only saving grace is that I still prefer this to a Windows CE device.

4. The ability to crash the system hard. I've already experienced this a few times. It's one thing to install a program that makes the palm behave poorly, or that causes it to reboot. However it's poor design for an operating system to be irreversibly put out of commission due to an installation. I've experienced the "reboot-loop" problem, where the device just reboots before it comes back into function fully. At the very least, Palm should include a FAILSAFE mode that allows you to delete certain items or at least back up your data before doing a hard reset. This feature combined with the inability for automatic un-monitored syncing (as mentioned in 3) really put a damper on my excitement about the device.

Sunday, April 16, 2006

Dancing on the Diodes

I probably should not admit it, but I do like to dance. Coupled with the fact that I am a geek, this disco-floor project at MIT really piqued my interest!