%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
\chapter{Experimental Results}\label{chapter:results}

POSSE has been extensively tested using various platforms for stability
and performance. In this chapter, tests demonstrating both the single
and multiple client performance of POSSE are presented.

\section{Single Client Performance}
Fig.~\ref{fig:bandwidth2} shows a plot of the effective network
bandwidth achieved by varying the size of a dynamic 1-D array requested
by a steering client. These tests were carried between machines
connected via a Fast Ethernet connection having a peak-theoretical
network bandwidth of 100 Mbps. The communication time used to calculate
the effective bandwidth includes the overheads for byte-ordering, data
packing and other delays introduced by the querying of the registered
data. The average latency for query of any registered data by the client
has been found to be $38$ ms. As can be seen, there is a noticeable
decrease in the bandwidth (about $10$ Mbps) when communicating between
machines with different byte-ordering (i.e., little endian vs. big
endian) as opposed to machines with the same byte-ordering. This
difference reflects the overhead involved in duplicating the requested
data and converting it into the byte-order of the client machine for
communication. In the same byte-order case, as the size of the requested
data increases to about $5$ MB, the effective bandwidth approaches
$80$ Mbps, which is $80 \%$ of the peak-theoretical bandwidth. The
source code for the programs used to carry out the test can be found in
Appendix~\ref{ch:scp}.

\myfigureW{figs/bandwidth2.ps}{bandwidth2}{12cm}
{Effective Network Bandwidth vs. Size of data requested by client}

\section{Multiple Client Performance}
Fig.~\ref{fig:bandwidth1} shows a plot of the effective
bandwidth achieved by varying the number of clients simultaneously
requesting data. In this test, both the clients and the server were
machines with the same byte-ordering. The server had a registered 4-D
array with $200,000$ {\em double} elements ($1.6$ MB of data). All the
clients were then run simultaneously from two remote machines on the
same network and were programmed to request the $1.6$ MB 4-D array from
the server. The effective bandwidth in this case is obtained by dividing
the total amount of data served by the server with the total wall-clock
time required to serve all the requests. It can be seen that the network
performance of POSSE is very good ($84$ Mbps) even when dealing with
over $500$ client requests simultaneously. 
The source code for the programs used to carry out the test can be found
in Appendix~\ref{ch:mcp}.

For the wake-vortex simulation system, the amount of data
communicated to the client after every update is 420 bytes for every
aircraft and 56 bytes for every vortex element. For 10 aircrafts each
having $2,000$ elements tracked, this amounts to $1.12$ MB of data.
From Fig.~\ref{fig:bandwidth2}, we can see that this corresponds to
a data-rate of approximately $62$ Mbps, or $145$ ms of communication
time. Thus, we can get updated data at a rate of almost 7 fps from the
server. The wake-vortex simulation runs with a $\Delta t$ of 0.2 seconds
which can be maintained for up to $2,000$ vortex elements per aircraft
on COCOA-2. The parallel code has very good scalability for up to 15
processors (tracking 15 aircrafts) after which it linearly deteriorates
due to the overhead borne by the master for distributing and collecting
data from the slave nodes. At this point, the simulation has only been
qualitatively checked and seems to be consistent with the theory. The
simplification of using $k$ neighbors for induced-velocity computation
works very well with an error of less than $1\%$ when compared to the
original $O(N^2)$ case. Since the weather conditions play a substantial
role in the determination of the vortex strength, a more sophisticated
weather model like the one used in AVOSS will definitely improve the
accuracy of the simulations.

\myfigureW{figs/bandwidth.ps}{bandwidth1}{12cm}
{Effective Network Bandwidth vs. Number of simultaneous clients}

\begin{itemize}
\item Talk about SMP vs single processor issues for the dataserver, and why
the multi-threaded approach is scalable across multiprocessor machines.
Try to quantify this with a plot. [This work is in progress....will be done in a few days.]
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
