[Olsr-dev] etx

[Rogge Henning]

I'm not sure I understand what you are exactly using for calculating the
link cost... can you maybe post the formula that calculates the new ETX
metric from the old one and the timestamp of both packets involved ?

You are combining your new ETX plugin with a normal one ? Or are you using
two of your plugins ?

What does "tcpdump -i <interface> -n -s 0 -vv port 698" says to your packets
?

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für 
Kommunikation, Informationsverarbeitung und Ergonomie FKIE 
Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg, 
Germany Telefon +49 228 9435-961,   Fax +49 228 9435 685 
mailto:(spam-protected) http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 

> -----Ursprüngliche Nachricht-----
> Von: Airton Ishimori [mailto:(spam-protected)] 
> Gesendet: Dienstag, 17. August 2010 13:45
> An: Rogge Henning
> Betreff: Re: [Olsr-dev] etx
> 
> I know that the codes are different and incompatible. My code 
> is based in the etx_float, but the type of data is not 
> floating point, it is integer.
> 
> I'm using a mechanism to calculate a time difference between 
> two packet P1 e P2 (for example) sended by all neighbors. I'm 
> using a repository of data to register this times difference. 
> And I created a function packet parser to get the olsr packet 
> (not olsr message) to handle the packets that caming my 
> neighbor. In this function, currently I calculate the times 
> difference and include (after some operation) the information 
> of the link quality lq. The repository of the times is the 
> linkquality[0] that is in link entry.
> 
> And so, the olsrd send the packet with link quality data 
> information to neigbhor, but this neighbor it seems that is 
> not keeping this link quality information that came.
> --
> Airton
> 
> 
> 
> 
> On Tue, Aug 17, 2010 at 04:25, Henning Rogge 
> <(spam-protected)> wrote:
> 
> 
> 	On Mon August 16 2010 21:28:29 Airton Ishimori wrote:
> 	> Hi,
> 	>
> 	> I'm implementing a "new etx". The calculate of the 
> etx is the same, but I'm
> 	> introducing some modifications in the etx based in 
> window (as the
> 	> etx_ffetch) implemented into olsrd-0.6. Basically, 
> the "new etx" don't
> 	> based in the windows, the calculate is based in the 
> moving average
> 	> techinique and time information to calculate the new etx.
> 	
> 	Can you compare your implementation to 
> etx_fpm/etx_float ? Both are moving
> 	average implementations of ETX.
> 	
> 	etxff_eth is an experimental ETX that handles "perfect" 
> ethernet connections
> 	as a special "ETX 0.1" case. It's incompatible with the 
> other ETX
> 	implementations.
> 	
> 
> 	> But the new etx is it "crazy", that is, I mean ... 
> the NLQ is always 0, as
> 	> if the memorize foreigen hello function not working 
> or the repository not
> 	> working to register the link quality information. 
> Anybody know, what is
> 	> happening?
> 	
> 	Most likely you mixed up code from 
> etx_ff/etx_fpm/etx_float with code from
> 	etx_ffeth. They use a different packet format to 
> prevent accidental mixing
> 	(which could create stable routing loops).
> 	
> 	Henning Rogge
> 	--
> 	Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
> 	Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> 	Kommunikationssysteme (KOM)
> 	Neuenahrer Straße 20, 53343 Wachtberg, Germany
> 	Telefon +49 228 9435-961,   Fax +49 228 9435 685
> 	mailto:(spam-protected) 
> http://www.fkie.fraunhofer.de
> 	GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
> 	
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7095 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100817/865a55d6/attachment.bin>