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