[OLSR-users] Network stability
Fri Apr 29 04:23:44 CEST 2005
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
Thanks for the thought, though.
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
More information about the Olsr-users