[Olsr-users] OLSRv2_DLEP_CODE: User view - metrics calculation from oonf_layer2 db

[s-mtafel]

Hey Henning,

thanks for coming back so quickly.

> you will find one function where the oonf_layer2 API is called (hint:
> search for "oonf_layer2_" in the file).
> 
> This is the place where the DAT metric queries the layer2 database
> about the incoming linkspeed... which could come directly from the
> nl80211_listener or the dlep_router subsystem.
>

Well, I should have told you that I have already found this calc. I
thoroughly greped for oonf_layer_ through the project. I just did not
know about DAT, this part seemed too laconic for the full metric calc.

Further, I have read the DAT RFC. But I do not fully get the interplay
of the metric calc. and the delivered dlep_modem info.

So far, the dlep_modem delivers interface specific radio data (at least
the mandatory msg data items) to the dlep router part and that maps the
received data into the oonf_layer2. Clearly readable in the oonf
implementation. Fine:  OONF_LAYER2_NEIGH_RX_BITRATE is the focal point
f. metric calc. as I unterstood. In ext_base/proto.c I can see the
mapping betw. DLEP_CDRR_TLV and OONF_LAYER2_NEIGH_RX_BITRATE. Also the
maping mechanism is obvious.

Ok. But the other dlep data items like latency or MDR are also mapped
into the oonf_layer2 data base. What is about them. Are those completely
ignored for metric determination? Do those not get melded into metrics
in some way? Seems odd somehow.

Maybe i did miss something? Thanks f. clarifying!

BR

Matthias T.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xAD8F5E23.asc
Type: application/pgp-keys
Size: 2588 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20151130/76c911bf/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20151130/76c911bf/attachment.sig>