----- Original Message -----
> Hi folks,
>
> I am slowly working on replacing all our internal scripts to collect network
> statistics. One value that sar gives out is %ifutil, which is defined as
> follows:
> """
> Utilization percentage of the network interface. For half-duplex interfaces,
> utilization is calculated using the sum of rxkB/s and txkB/s as a
> percentage
> of the interface speed. For full-duplex, this is the greater of rxkB/S or
> txkB/s.
> """
>
> Code:
> double compute_ifutil(struct stats_net_dev *st_net_dev, double rx, double tx)
> {
> unsigned long long speed;
>
> if (st_net_dev->speed) {
>
> speed = st_net_dev->speed * 1000000;
>
> if (st_net_dev->duplex == C_DUPLEX_FULL) {
> /* Full duplex */
> if (rx > tx) {
> return (rx *
> 800 /
> speed);
> }
> else {
> return (tx *
> 800 /
> speed);
> }
> }
> else {
> /* Half duplex */
> return ((rx + tx) * 800 /
> speed);
> }
> }
>
> return 0;
> }
>
> Two questions:
> 1) Would it be ok to add this to the Linux PMDA or do you feel this is
> something to be taken care of
> by higher-level apps/tools or via some combined metric?
I think the tx and rx values being passed into that function would be
rate-converted counters? (throughput) - which requires two samples to
calculate. If so, I guess client side calculations would be the way
to go - these look like candidate metrics that'd be involved...
network.interface.speed
network.interface.baudrate
network.interface.duplex
network.interface.in.bytes
network.interface.out.bytes
> 2) In case the answer to 1) is 'it is ok', is the above calculation ok? I'm
> not entirely convinced.
> I'd personally split it in %rx_ifutil and %tx_ifutil. Thoughts?
Yeah, does seem a little odd, though I'm far from a networking guru.
If it was storage, we'd be summing the in/out rates to calculate the
utilisation, not taking the biggest and ignoring the other. I think
having the separate send/recv values is a good idea anyway.
cheers.
--
Nathan
|