[Nodeshot] TX, RX rate

[Clauz]

Hi.
Yesterday we talked about this in person, I try to summarize and add
something more, replying inline.

On 11/07/2013 10:24 AM, nemesis wrote:
> In the new database, every interface type has a tx_rate and rx_rate field.
> 
> The link table has a tx_rate and rx_rate too, which in the beginning the
> idea was to represent the average between interface A and interface B (a
> link connects two interfaces).
> 
> Interface types can vary: ethernet, wireless, tunnel, bridge... we'll
> work out in details these later.
> 
> My question is: does it have sense to have the tx_rate and rx_rate on
> every interface?
> 
> Or is mainly a proprety related to wireless interfaces?

We are talking about tx and rx association rates. These are mainly
related to wireless interfaces, but also wired interfaces do some
negotiation. On Linux try:
# ethtool eth0 | grep Speed

It might make sense for all physical network interfaces, but I think
that for the moment we can happily ignore bluetooth, firewire, KORUZA,
etc. and just consider wireless 802.11 and wired ethernet.

> Does it have sense for example.. to have tx_rate and rx_rate on a vpn
> interface? Or on a bridge interface?

No.

> Going back to links... does it really have sense to have tx/rx on the
> link? If yes should it be the average between the two interfaces or one
> of the two? I remember having discussed this with some of you.. probably
> ZioProto but cannot remember right now.

On one link, the tx for one side is the rx for the other. I would keep
both values, but that would mean giving a direction to the link? What
about using "min_rate" and "max_rate"?



> So to summarize, the questions are:

Summarizing my opinions below:

> * should every interface type have tx_rate and rx_rate or not?

No.

> * if not, which types?

Only wireless 802.11 and wired ethernet.

> * should link objects have tx_rate and rx_rate?

Yes.

> * if yes how should those values be determined?

min_rate and max_rate instead of computing the average.

ciao,
Clauz



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/nodeshot/attachments/20131108/2f6c00f9/attachment-0001.sig>