<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">>In
fact,
for
ETT
(Expected
Transmission
Time)
you
need
the
medium
speed<br>>(mbit/s).
Then
you
can
use
the
formula:<br><br>
>ETT
=
ETX
*
#bits
/
bitspeed<br><br>>RTT
may
be
an
indication
of
bit
speed
but
I'm
not
sure
if
that
metric
is<br>>very
suitable,
especially
for
quite
asymmetric
links
(unlink
speed
different<br>>from
downlink
speed).<br><br>>At
Thales
we
developed
a
plugin
that
measures,
once
every
so
many
minutes,<br>>the
speed
of
the
available
network
interfaces.
This
is
done
using
a
variant<br>>of
the
well-known
packet-pair
technique.
It
is
purely
layer-3,
so
no<br>>nterfacing
with
layer-2
metrics.
That
plugin
determines
the
speed
of
a<br>>network
interface
by
measuring
the
bitspeed
with
the
best
neighbor.<br>>Unfortunately,
at
this
moment
I
do
not
have
permission
to
publish
this<br>>plugin.<br><br>>Of
course
there
are
many
other
ways
to
measure
the
speed.
And,
in
absence
of<br>>any
automatic
measuring
method,
one
could
also
fall
back
to
setting
the<br>>speed
values
manually
to
a
fixed
value.<br><br>>In
all
cases,
whichever
speed
measurement
you
implement,
the
ETT
extension<br>>that
we
implemented
offers
a
way
(you
may
call
it
"interface")
for
the<br>>measurement
plugin
to
tell
the
extension
what
speed
is
experienced
on
each<br>>available
network
interface.
Currently
the
"interface"
with
ETT
is
a
bit<br>>limited
since
it
will
only
accept
a
speed
value
per
network
interface,
not<br>>per
neighbor
(per
link).
This
is
because
our
current
measurement<br>>(packet-pair)
plugin
can
only
give
per-interface
data.
However,
it
would
not<br>>difficult
to
to
enhance
the
ETT
extension
so
that
it
can
deal
with
separate<br>>bit
speed
measurements
for
each
neighbor
(link)
that
can
be
reached
on
a<br>>given
network
interface
(in
the
same
way
that
ETX
values
are
passed
per<br>>neighbor/per
link).<br><br>>An
alternative
to
measuring
(via
RTT
or
packet-pair
methods)
would
be
to<br>>write
a
plugin
that
retrieves
layer
2
information,
as
you
propose.
An<br>>existing
implementation
might
be
found
the
XIAN
framework;
see<br><a href="http://xian.sourceforge.net/" target="_blank">>http://xian.sourceforge.net/</a>
.<br><br>>If
you
have
an
example
of
source
code
that
can
read
out
layer-2
metrics
I<br>>would
be
very
interested
!<br><br>Erick<br>-------------- <br>
With respect to the RTT issue:<br>
---> with popular MADwifi driver, the transmission rates are reported in<br>
/proc files, so getting it shouldn't be a challange.<br>
However, implementing packet pair in the current OLSR versions<br>
is another possibility.<br>
Can you share your code for the ETT modifications?( for the part you have permission)<br>
Lets get inside the code make ETT possible.<br>
<br>
Lochan.<br><br><br></div><br></div></div><br>
<hr size=1>Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. <a href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ "> Try it now.</a></body></html>