Re: [B.A.T.M.A.N.] any throughput mechanism or plans?

[Marek Lindner <lindner_marek@yahoo.de>]

On Monday, April 02, 2012 15:35:35 dan wrote:
> > This will result in a metric optimizing paths for the highest throughput
> > ever recorded. In reality one can easily observe many links with
> > variable throughput. Sometimes you get a spike of high throughput
> > although the average speed is lower. Or your wifi environment changes
> > with a negative impact on the throughput.
> 
> True. maybe not keep the maximum.  Maybe watch the interface queue and
> measure the throughput when frames start to get queued.  Updated the
> 'max' speed whenever an interface starts to queue frames.

Watching the interface queue would be very interesting for other features as 
well but turns out to be hard in practice. A while ago Simon and others tried 
to improve the interface alternating / bonding by monitoring the fill status 
of the queue. But the wifi stack does not report the fill status. Even if it 
did we don't know what is going on in the hardware.

We still have the problem that some links might be idle, therefore we will 
have to generate traffic before we can evaluate these links.


> > Yes, we still have the "costly" way of detecting the link throughput
> > ourselves. What do you think about the idea of asking the wifi rate
> > algorithm for the link speed ?
> 
> I am a wisp.  In my experience, the wifi sync rate isn't reliable.  In
> perfect conditions yes, but when there is fresnel zone incursion on a
> wireless link, the algorythm can't take into account reflected signal
> as noise because they dont exist yet.  Not until you start transfering
> data does the signal get reflected back (as noise) and the radio has
> to adjust the rate down.  Problem is that this happens after you have
> dropped 5% of your packets, which would drop the TQ on the link and it
> would be effectively down until.  Now the data stops, reflections
> stop, link changes speed back up and very light use (pings, OGMs)
> travel safely and TQ rises. Rinse and repeat.

Sounds very similar to the problem above: Without traffic we can't be sure 
about the possible throughput.


> I wish I had a really great solution to this.  I dont really have
> anything to complain about, batman-adv is already a mile ahead of the
> next best mesh routing protocal :)

Thanks for the flowers!  :-)
Still, we have some work ahead of us. Throughput based routing is a hot topic 
we want to work on. All ideas are welcome.

Cheers,
Marek