[Olsr-dev] Is there olsrd with ETT implementation

[Chiang Kang Tan]

Hi Lochan,
    I agree that the transmission rate can be obtained using the MADwifi driver,
but RTT is not ETT (correctly me if I'm wrong) and so it's obtained differently.
Link layer RTT should be calculated from when the MAC frame is ready to be
send (before backoff, considering that 802.11 is used) till an ACK frame is
received. With the MADwifi driver (not the ath5k I hope when it's ready), I
think there's no way of getting RTT at that level, as the HAL is not open source.
I guess some compromise in accuracies is probably acceptable, since ETT is
based on some estimation?

cheers
Chiang 


----- Original Message ----
From: lochan verma <(spam-protected)>
To: (spam-protected)
Sent: Friday, 25 January, 2008 1:45:48 PM
Subject: Re: [Olsr-dev] Is there olsrd with ETT implementation

>In 
fact, 
for 
ETT 
(Expected 
Transmission 
Time) 
you 
need 
the 
medium 
speed
>(mbit/s). 
Then 
you 
can 
use 
the 
formula:

 
>ETT 
= 
ETX 
* 
#bits 
/ 
bitspeed

>RTT 
may 
be 
an 
indication 
of 
bit 
speed 
but 
I'm 
not 
sure 
if 
that 
metric 
is
>very 
suitable, 
especially 
for 
quite 
asymmetric 
links 
(unlink 
speed 
different
>from 
downlink 
speed).

>At 
Thales 
we 
developed 
a 
plugin 
that 
measures, 
once 
every 
so 
many 
minutes,
>the 
speed 
of 
the 
available 
network 
interfaces. 
This 
is 
done 
using 
a 
variant
>of 
the 
well-known 
packet-pair 
technique. 
It 
is 
purely 
layer-3, 
so 
no
>nterfacing 
with 
layer-2 
metrics. 
That 
plugin 
determines 
the 
speed 
of 
a
>network 
interface 
by 
measuring 
the 
bitspeed 
with 
the 
best 
neighbor.
>Unfortunately, 
at 
this 
moment 
I 
do 
not 
have 
permission 
to 
publish 
this
>plugin.

>Of 
course 
there 
are 
many 
other 
ways 
to 
measure 
the 
speed. 
And, 
in 
absence 
of
>any 
automatic 
measuring 
method, 
one 
could 
also 
fall 
back 
to 
setting 
the
>speed 
values 
manually 
to 
a 
fixed 
value.

>In 
all 
cases, 
whichever 
speed 
measurement 
you 
implement, 
the 
ETT 
extension
>that 
we 
implemented 
offers 
a 
way 
(you 
may 
call 
it 
"interface") 
for 
the
>measurement 
plugin 
to 
tell 
the 
extension 
what 
speed 
is 
experienced 
on 
each
>available 
network 
interface. 
Currently 
the 
"interface" 
with 
ETT 
is 
a 
bit
>limited 
since 
it 
will 
only 
accept 
a 
speed 
value 
per 
network 
interface, 
not
>per 
neighbor 
(per 
link). 
This 
is 
because 
our 
current 
measurement
>(packet-pair) 
plugin 
can 
only 
give 
per-interface 
data. 
However, 
it 
would 
not
>difficult 
to 
to 
enhance 
the 
ETT 
extension 
so 
that 
it 
can 
deal 
with 
separate
>bit 
speed 
measurements 
for 
each 
neighbor 
(link) 
that 
can 
be 
reached 
on 
a
>given 
network 
interface 
(in 
the 
same 
way 
that 
ETX 
values 
are 
passed 
per
>neighbor/per 
link).

>An 
alternative 
to 
measuring 
(via 
RTT 
or 
packet-pair 
methods) 
would 
be 
to
>write 
a 
plugin 
that 
retrieves 
layer 
2 
information, 
as 
you 
propose. 
An
>existing 
implementation 
might 
be 
found 
the 
XIAN 
framework; 
see
>http://xian.sourceforge.net/ 
.

>If 
you 
have 
an 
example 
of 
source 
code 
that 
can 
read 
out 
layer-2 
metrics 
I
>would 
be 
very 
interested 
!

Erick
-------------- 

       With respect to the RTT issue:

        ---> with popular MADwifi driver, the transmission rates are reported in

                /proc files, so getting it shouldn't be a challange.

                However, implementing packet pair in the current OLSR versions

                is another possibility.

      Can you share your code for the ETT modifications?( for the part you have permission)

      Lets get inside the code make ETT possible.



Lochan.








      Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20080125/9b7555cf/attachment.html>