[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
aaron.
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