Re: [B.A.T.M.A.N.] [PATCH 0/5] alfred: TQ query optimizations

[Simon Wunderlich <sw@simonwunderlich.de>]

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

On Wednesday, May 24, 2017 12:31:28 PM CEST Sven Eckelmann wrote:
> Hi,
> 
> alfred uses the TQ from batman-adv to find its best alfred neighbor. This
> best neighbor information is used by slave servers to request/publish data.
> 
> This is done for each server announcement packet by:
> 
>  * requesting the global translation table (netlink or debugfs) and then
>    searching in it for the MAC address of the detected alfred server to find
> its originator address
>  * requesting the originator table (netlink or debugfs) and then searching
> it it for the originator address of the detected alfred server to find its
> TQ value
> 
> This was previously done whenever a new announcement packet received by
> alfred. We've observed that this can be a problem on networks with a lot of
> master servers (~100) which can see each other, large translation tables and
> slow CPUs. alfred still worked but the CPU load by alfred was rather high
> (~20% on an 560MHz AR9344).
> 
> The idea is now to avoid this lookup for master servers. And (for slave
> servers) to process all servers at once. This is done before the wants to
> push its local data to a master server in an sync interval.
> 
> The process which was described earlier was now changed to:
> 
>  * requesting the global translation table (netlink or debugfs) and then put
> MAC address and corresponding originator address in tg hash
>  * requesting the originator table (netlink or debugfs) and then put
>    originator address and corresponding TQ value orig hash
>  * got through all servers:
>    - search in tg hash for for the MAC address of the alfred server to find
>    its originator address
>    - search in orig hash for for the originator address of the alfred server
> to find its TQ value
> 
> These changes reduced the load on the previously mentioned devices
> significantly.

I've applied this patch series with some fixes in patch 4 and 5 regarding the 
hash initialization.

Thank you,
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]