If you are willing to test a few things to reduce the effect we can start right away. You could set TQ_GLOBAL_WINDOW_SIZE to 1 in order to deactivate the averaging of the TQ values. Aslo, some people reported that reducing the hop penalty also will increase the speed.
I already tried changing TQ_GLOBAL_WINDOW_SIZE to 5 instead of 10 and that helped. Changing it to one is interesting. I've not tried it yet, but i would of thought some ring buffer was needed to handle the 0s which are added when originator messages are received for other neighbors.
I already tried reducing the hop penalty. However testing showed it behaved worse. This i don't understand. So i'm guessing my test setup changed between my different tests. So i need to run the test again, both the control and the modified hop penalty.
What ideas do you have for improving the algorithms. Depending on the scale of work needed i might have some time to do some coding.
Andrew
On Wednesday 24 June 2009 16:28:45 Andrew Lunn wrote:
I already tried changing TQ_GLOBAL_WINDOW_SIZE to 5 instead of 10 and that helped. Changing it to one is interesting. I've not tried it yet, but i would of thought some ring buffer was needed to handle the 0s which are added when originator messages are received for other neighbors.
Oh yeah, you right about the 0s.
What ideas do you have for improving the algorithms. Depending on the scale of work needed i might have some time to do some coding.
I'd suggest we discuss this in a more interactive mode as chatting via IRC. What about the batman IRC channel ?
Regards, Marek
What ideas do you have for improving the algorithms. Depending on the scale of work needed i might have some time to do some coding.
I've been sending Simon and Marek some emails lately about some ideas for dynamic originator intervals. Basically the idea was, to not use any external devices like GPS (weather station, news paper articles, fortune tellers, ...) for detecting the dynamicness of the environment and changing the OGM-interval on those pieces of information, but that the information about the changes of the TQ-values over time should be sufficient to detect changing conditions.
If you (or others) might be interested, I could translate those ideas to English and post them on our wiki-page. I would love to get some more feedback and enhancements to them.
Cheers, Linus
On Wed, Jun 24, 2009 at 11:06:31PM +0200, Linus Lüssing wrote:
What ideas do you have for improving the algorithms. Depending on the scale of work needed i might have some time to do some coding.
I've been sending Simon and Marek some emails lately about some ideas for dynamic originator intervals. Basically the idea was, to not use any external devices like GPS (weather station, news paper articles, fortune tellers, ...) for detecting the dynamicness of the environment and changing the OGM-interval on those pieces of information, but that the information about the changes of the TQ-values over time should be sufficient to detect changing conditions.
That probably does not help my situation when a node goes away. I'm guessing a node in a vehicle will vanish from the mesh very quickly. I don't currently know in our situation if it is normal to perform a shutdown, or if it just drives off.
It is not a general solution, but i did wonder about adding support for signalling a node is shutting down. It could say broadcast a BAT_BYE message, 5 times at 20ms intervals. Neighbors who receive such a message would then take the originator straight out of their tables, picking another neighbor for the next hop if possible.
Getting the ordering right during shutdown could be interesting. We need the bat0 interface to be put down before other interfaces it depends on. So long as the init.d files have the correct priority this should be possible.
If you (or others) might be interested, I could translate those ideas to English and post them on our wiki-page. I would love to get some more feedback and enhancements to them.
I would be interested. By the way, what language are they currently in? I read German if that is any help.
Andrew
b.a.t.m.a.n@lists.open-mesh.org
-
Andrew Lunn -
Linus Lüssing -
Marek Lindner