[olsr-dev] Re: cpu load?

aaron (spam-protected)
Thu Jun 2 20:13:30 CEST 2005

hi thomas,

another observation apart from the strange behaviour/potential bugs 
i wrote about last time: is link qaulity calculation (ETX)
based on a sliding window mechanism or is etx calculated as in link_set.c:870 ?

In the later case: would a sliding window make more sense?
What happens when you don't have a sliding window:

packet 0.. packet i-1: zero packet loss
------- snip --- now ---
packet i, ok, update etx
packet i+1, packet is lost -> link quality = 50% packet loss -> etx is bad
packet i+2 ... packet i+19 : packet is good, packet loss = 1/20.
---- snip ---
packet i+20...packet i+infinity, everything ok

NOW, if you use a sliding window all the time, you will have only link quality 
19/20 . If you dont use sliding window etx will sometimes become 2.

any mistakes in my thoughts?

thanks for your time 

On Thu, Jun 02, 2005 at 12:48:25AM +0200, aaron wrote:
> On Wed, Jun 01, 2005 at 11:21:37PM +0200, Thomas Lopatic wrote:
> > Hi Aaron.
> > 
> > Thanks for bringing this to our attention. Let me ask a few questions to
> > get a better feeling for this problem.
> > 
> > * How do you measure the packet loss? Is this the packet loss detected by
> > olsrd (i.e. the LQ value) or is this the packet loss detected by
> > SmokePing?
> > 
> hi!
> i am talking about packet loss to the extend of "this node is dead"
> The funny thing ist: it will just as well even occur on pure ethernet 
> connections. 
> > * I assume that we're talking about packet loss on a single link here,
> > e.g. between nodes A and B. Does olsrd report a high packet loss (i.e. LQ
> packet loss / "node is almost dead" for a random (or seemingly random) number of nodes. At first it looked like it affected only omni nodes but actually it happend to our dot_draw plogin / map painting machine b) to most omnis and c) to 
> some cable connected directional link nodes (all of them excpet for the pcs)
> are linksys
> almost dead means: it will take a very long time until a ping goes thru
> or until we can conect via ssh
> > value) on both nodes involved in the link, i.e. on A and on B?
> > 
> it seems hard to reproduce.. .i will keep my eye open and try to 
> connect again when that happens . but as soon as i retart olsrd it works fine. 
> so if i restart olsrd with -d 1 then all seems ok :)
> > * Which of the two nodes do you have to reboot to make the problem go
> > away? Both? Or only the one that reports the high packet loss? Or only the
> > other node?
> > 
> hm good one. so far i rebooted most of them and everything was ok again.
> > * Do you have to reboot the node to make the problem go away or is it
> > sufficient to restart olsrd?
> > 
> see above.
> sorry if my report is a bit unspecific. It is just hard to track down. 
> but questions like these help already.
> > Thanks,
> > -Thomas
> > 
> -- 
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev


More information about the Olsr-dev mailing list