[OLSR-users] Network stability

[John Gorkos]

That's a possible scenario, but the one user is strictly a web-browser type, 
and the other wasn't even home when I was testing the link.
I'm going to put wondershaper on all of the eth1 interfaces in the network, 
and limit outbound traffic to maybe 1mbps, and possibly give olsrd packets 
higher priority in the overall scheme of things.  I'm just now getting my 
brain wrapped around traffic shaping, so it might be a while before I get all 
the priorities down to a science.

I can tell you that the 26 or so users I have on the mesh use 2-3x more 
bandwidth than my point-to-multipoint customers do.  I just provisioned a 
brand-spanking new 6mb/s DSL line for them today.  Hopefully that will keep 
them happy.

Thanks for the thought, though.

John Gorkos

On Thursday 28 April 2005 16:59, aaron wrote:
> hi John!
>
> Does the net have lots of traffic?
> We experienced that when somebody is really sucking large scale GBytes
> from a close by server then the OLSR packets themselves can't get thru
> anymore sometimes. That we he loses his own route because he was
> downloading to many movies.
> -> "OLSR packet starvation"
>
> Could that be the problem you are experiencing?
>
> On Thu, Apr 28, 2005 at 12:15:56PM -0500, John Gorkos wrote:
> > On Thursday 28 April 2005 11:58, Thomas Lopatic wrote:
> > > Hey John.
> > >
> > > Hmmm. So the user's link to the tower times out on a regular basis
> > > which then causes the indirect route via another user's node to be
> > > taken to the tower?
> >
> > I think.  It happens so fast, that I can catch it in the act.  The debug
> > dump from the routers scrolls faster than I can catch it.
> >
> > > If so, you might want to increase the HelloValidityTime and the
> > > TcValidityTime to, say, twice or three times their original values in
> > > order to not use the link.
> >
> > HelloValidityTime       20.0
> > TcValidityTime          40.0
> >
> > > You should then also change HystScaling to something smooth, e.g. 0.1,
> > > which will make hysteresis less sensitive to changes in the link
> > > quality. Moreover, you could lower HystThrHigh to something like 0.6
> > > and HystThrLow to something like 0.2, the effect being that the link is
> > > more easily accepted as established by hysteresis (hysteresis value
> > > higher than HystThrHigh) and less prone to being rated as broken
> > > (hysteresis value lower than HystThrLow).
> >
> > HystScaling     1.00
> > HystThrHigh     0.60
> > HystThrLow      0.20
> >
> > > (You're still not using link quality, right?)
> >
> > No.  I'm torn over this one.  I want to, but I also don't want to deviate
> > from the RFC, and I don't want to risk stranding a router when I change
> > over.
> >
> > > -Thomas
> >
> > Thanks, as always.  I'll go run these tests and let you know how it
> > looks. How far through the network should I propagate these?  Every
> > affected router?
> >
> > John Gorkos
> > _______________________________________________
> > olsr-users mailing list
> > (spam-protected)
> > https://www.olsr.org/mailman/listinfo/olsr-users