Re: RFC: NetworkManager Device Statistics





On Thu, May 26, 2016 at 1:44 AM, Tony Espy <espy canonical com> wrote:
On 05/25/2016 12:45 PM, Dan Williams wrote:
On Wed, 2016-05-25 at 18:10 +0200, Thomas Haller wrote:
On Tue, 2016-05-24 at 12:51 -0400, Tony Espy wrote:

We have a new requirement to add a data activity indicator to
Ubuntu
Touch for certification in certain markets.

We've had some internal debate about whether or not we should
extend
NetworkManager to provide this information to the rest of the
system
vs.
adding logic directly to our touch-specific network indicator.
Hi Tony,


IMO it would be interested in having this in NetworkManager, and I
think we would be willing to help with implementation.

Yeah, it's been brought up before and it just needed somebody to do it
:)

Cool.  We're on it then!

As with the previous reply, CC'd Alfonso.

The current prototype is based on a similar facility in Connman,
and
involves RTM_GETLINK polling to retrieve device-specific Rx and Tx
statistics.
Do you have a prototype available somewhere?




Connman's API can be seen here:

https://git.kernel.org/cgit/network/connman/connman.git/tree/doc/co
un
ter-api.txt
https://git.kernel.org/cgit/network/connman/connman.git/tree/doc/ma
na
ger-api.txt#n90

Our proposed implementation involves extending
NMPlatform/NMLinuxPlatform and adding some new properties to the
NetworkManager.Device interface:

* TxBytes, TxPackets, [calculated TxRate (byte/s)] and Rx
equivalents
* EnableStatProps : boolean property to enable/disable device
statistics
* StatPropsRefreshRateMs : refresh rate for Tx/Rx properties in
milliseconds

An alternative to extending the Device interface would be adding a
dedicated Device.Statistics interface; and perhaps a Device
interface
method ( vs. the EnableStatProps property ) to control
enabling/disabling collection of statistics on a per-device basis.

The idea behind EnableStatProps is to avoid overloading the system
with
PropertiesChanged signals. The Tx/Rx properties will not refresh
if
EnableStatProps is false, and will refresh, sending
PropertiesChanged
signals with the rate specified in StatPropsRefreshRateMs, when
true.
In our case, we'd explicitly disable statistics when the screen on
a
device is turned off.

Maybe EnableStatProps could be dropped, and is implicit by
setting StatPropsRefreshRateMs to zero.

I would say that the new Device.Statistics interface would simply have
a "RefreshRateMs" property (eg, no StatProps prefix) which would be set
to > 0 to enable reporting via D-Bus.  Then have the Tx/Rx statistics
as properties of the interface as well, that stay zero when reporting
isn't enabled or is turned off.

Sounds like a good approach to me.  Alfonso?

Sounds sensible to me, let's go this way.

Br,
Alfonso
 


/tony




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]