On 12/02/14 13:27, Antonio Quartulli wrote:
On 12/02/14 09:58, Andrew Lunn wrote:
On Tue, Feb 11, 2014 at 01:48:14PM +0100, Antonio Quartulli wrote:
From: Antonio Quartulli antonio@open-mesh.com
Implement a stub get_throughput() function which returns the estimated throughput towards a given neighbour. Its result is then used to compute the metric value.
The metric is updated each time a new ELP packet is sent, this way it is possible to timely react to a metric variation which can imply (for example) a neighbour disconnection.
It is very much a style issue, but i would probably split this into two patches. Updating the metric at send time rather than receive should have nothing to do with estimated bandwidth.
Yes, to make it easier I will first move the reading at sending time and then I'll introduce the throughput estimation.
Andrew,
I just rechecked the code and I realised that these "2 changes" are one only because there is no "second change".
Before this patch ELP does not perform any metric estimation.
This patch adds the estimation mechanism and in particular adds it along the ELP message sending path.
Maybe this was not clear? Maybe some previous patch gave you the impression that a sort of metric estimation was already performed in the receiving routine?
Cheers,