[Nodeshot] TX, RX rate

[Clauz]

On 11/08/2013 12:17 PM, nemesis wrote:
> 
> [CUT]
> 
> 
>>> 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.
> 
> do you mean:
> 
> * min_tx_rate
> * min_rx_rate
> * max_tx_rate
> * max_rx_rate

No, this means that you have a "rx" and "tx" side. How do you choose
which side is rx and which side is tx? What I was suggesting is
replacing the pair (rx_rate, tx_rate) with the pair (min_rate, max_rate).

> Sounds good. On the UI we could show an average with
> besides/below/onrollover all these values.
> 
> Will it be problematic to update all these info very often?
> 
> Immagine the flow:
> 
> 1. system goes to find the tx/rx, dbm, ecc.
> 2. updates Interface A
> 3. updates Interface B
> 4. updates Link object
> 
> They're not very complex queries though, it should be ok.

It depends on how you implement point 1. Using ssh to connect to all
nodes very often looks to me like adding a lot of overhead to the network.

> I was thinking to implement some realtime updating too, for example, you
> open up a device in the web interface, and you get real-time data
> through a websocket connection between the browser and the server, the
> server retrieves the info via one of the "connectors" (SSH, SNMP, HTTP,
> ecc) every x secs and sends it back to the all the listening browsers on
> that channel (so each opened device page will be a channel in order to
> avoid crashing the server in case of many users watching the same page).

wow!

> I'm worried that the final result will be heavy from a hardware resource
> point of view (many queries, often). I already see that when performing
> some operations many queries are generated, but maybe we can take care
> of optimization later.

The overhead might be related to the connection method (e.g. ssh), I
don't think actual queries are heavy.

> Pheraphs here there are some optimization or profiling experts?

not me :)

> Anyone has experience in profiling / automated performance testing /
> stress test?

To get an idea of what is happening perhaps we can just run "top" on the
devices while running "information fetching" scripts.

Clauz