| >The description for the mib variable is total number of octets
>received on the interface. The customer seems to think that in fact
>it is octets per second. Can anyone explain this?
Yes. The customer is wrong :-)
It is a counter, not a rate. Applications typically sample this counter
and sysUpTime, then calculate utilization. (NetView probably can do this
for you, I'm not a NetView person.)
>Also with compression on the routers is the number of octets before
>or after compression. (ie the serial side or the ethernet side)
I don't really understand this question, but would think ifInOctets counts
octets received at the interface, regardless of whether or not a higher layer
will compress or expand them.
Mike
|
| In my experience...
I agree the ifinoctets and ifoutoctets, as presented by NETVIEW, is on a per
second basis.
Thus you do not need to normalise data across any time period as NETVIEW
appears to be doing it for you.
Thus to get line utilisation just: ifinoctets * 8 / linespeed * 100
Its easy to prove this. The data would be an increasing number if it were'nt
already normalised for you. Also if you collect "bits" instead of "Octets" and
divide by the line speed you get the same answer as octets*8/linespeed.
Something also to be aware of...
If you use the standard % UTILISATION data gathering mechanism
(bandwidthutilhd) then beware as this is taking both "in" data AND "out" data
but only dividing by the line speed. Thus the resulting data is out of 200%
not 100%!
Hope this helps.
Cheers, Jim
|
| >In my experience...
>I agree the ifinoctets and ifoutoctets, as presented by NETVIEW, is on a per
>second basis.
I hope I haven't confused the issue. I was referring to the values returned
by a conformant SNMP agent. These values (as displayed by a MIB browser)
are counters, not rates. They always increase until they wrap to 0, or
some discontinuity occurs (interface/agent go down).
If NetView has some other display/function that automatically does sampling
and rate calculation, that's beyond my knowledge.
Mike
|