<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffff00" text="#000000">
<br>
<blockquote cite="mid4621F23C.2060404@ieee.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<font face="Franklin Gothic Demi">ALl, <br>
Giuseppe has addressed a very important point. <br>
<br>
In fact the following question is a basic one: what is to be
investigated - an ideal behavior of the envisioned,<br>
precisely defined solution - or THE behavior of really deployed
products? <br>
<br>
In the WINTECH 2006 workshop </font><font size="-1"><font
face="Franklin Gothic Demi">The First ACM International Workshop on
Wireless Network Testbeds, Experimental evaluation and CHaracterization
</font>- <font face="Franklin Gothic Demi">one of the MOBICOM 2006
workshops - <br>
</font></font><font face="Franklin Gothic Demi">a very interesting
paper presents <br>
"An Empirical ANalysis of Heterogeneity in IEEE 802.11 MAC protocol
implementations and it implications"<br>
<br>
Surprisingly enough, besides of a long list of differences which are to
be expected _ e.g. rate adaptation<br>
algorithms are NOT defined by the standard, propreitary solutions have
to be used! - also <br>
very clear violations of the standard have been observed within
products of major manufactureres. <br>
<br>
In particular the list of observed differences (and violations of the
standard!) has been given, <br>
along with a demonstration, that due to this differences unfairness in
bandwidth sharing exists among terminals <br>
using products of different manufactures. And the differences ARE
SIGNIFICANT! <br>
<br>
So the question: throughput of an 802.11 is in fact unspecified -
sorry.... <br>
<br>
On the other hand : throughput of an 802.11 implementation by Company
XXX model YYYY from August 200z<br>
is probably not what one is necessarily looking at....
or perhaps exactly what one is looking at!<br>
<br>
Best <br>
adam wolisz<br>
</font>
<blockquote><font size="-1"><font face="Franklin Gothic Demi"><br>
</font></font></blockquote>
<font size="-1"><font face="Franklin Gothic Demi"> </font></font><br>
Giuseppe Bianchi wrote:
<blockquote
cite="mid46216B6000000265@relay-pt1.poste.it%3E%20(added%20by%0D%0A%09postmaster@poste.it)"
type="cite">At 00.40 15/04/2007, U.Shanker wrote: <br>
<blockquote type="cite">Detlef Bosau wrote: <br>
<blockquote type="cite">Jeroen Massar wrote: <br>
<blockquote type="cite">Durga Prasad Pandey wrote: <br>
<br>
<blockquote type="cite">What would be considered the best
network simulator(s) for wireless <br>
networks, particularly for TCP experiments? <br>
<br>
</blockquote>
<br>
A large amount (>40) old laptops spread around a site. <br>
<br>
Don't simulate, use real live setups. <br>
</blockquote>
<br>
Unfortunately, that´s not always possible. <br>
</blockquote>
Agreed <br>
</blockquote>
<br>
And don't neglect the fact that, at least for 802.11 networks (the area
which I'm experimentally more confident), there is a strong dependence
on the network cards / Drivers / OSs employed. For at least two reasons
(at least = limiting to what I'm personally aware of): <br>
<br>
1. it is not granted that ALL cards will exactly behave as specified by
the 802.11 standard (e.g. some use different CWmin, different EIFS, in
some cases odd behavior do emerge e.g. because of possible
implementation issues) <br>
<br>
2. they may also employ proprietary algorithms, either expected (such
as rate adaptation) or, and this is the case that may really play havoc
with your experiments, unexpected (e.g. one ongoing finding is that
some cards seem to use undocumented proprietary power control solutions
which you would not nearly expect from a wire-powered device!). <br>
<br>
This implies that, in order to have a reasonable confidence that the
experimental trial is meaningful (at least from a qualitative point of
view, e.g., to assess e.g. dependence from a set of system parameters),
you have to use homogeneous systems, and it is quite costly to deploy
more than a few identical boards/PCs, with identical card model and
driver version... Another possibility is to repeat the experiment with
different HW/SW and HOPE that results are the same. Not only this
doubles the cost and labor, but in many cases this is not even
technically possible (e.g. when your solution uses some driver-level
mechanism or requires driver modification). In any case, some care
(and, most important, the understanding if the hardware/software you
are using shows some odd behavior) is needed before taking conclusions,
especially in stressful conditions (e.g. many terminals, outdoor
links). <br>
<br>
Giuseppe. <br>
<br>
<br>
<br>
</blockquote>
</blockquote>
</body>
</html>