[Orca-users] Interface speed assumptions
David Michaels
dragon at raytheon.com
Fri Aug 21 09:45:56 PDT 2009
On 8/14/2009 10:00 AM, Hudes, Dana wrote:
> I've got the newer version of Orca (can't seem to find the version
> number in any of the files). In the orcallator.cfg used for the
> server, I see in the network interface computations the assumption
> that a gigabit-capable interface is in fact running at gigabit speed.
> I have systems where we don't have enough copper gigabit switch ports
> and therefore the interface is running 100 FDX -- and in fact I have
> one now, and this maddingly happens because of our network group,
> which has autonegotiate mismatched and therefore is at 100HDX (I have
> had other, 100Mbit interfaces such as hme where they screw up
> autonegotiate and I end up with 10HDX).
> How do I work around this assumption? We DO have ce interfaces, both
> old Sun gigaswift fiber cards and newer copper gigabit ports, which
> are running at gigabit speed.
That's a tricky one. I suppose you could take out the data_max line in
those graphs, and they'll be computed based on whatever the highest
value is for that bracket of time, but that's not useful for
cross-the-board comparisons. I would say that rather than change how
your data is presented, you should fix your autonegotiation problems.
You paid for 1gb, you should be getting 1gb. ;) We had that problem in
our Sun shop also -- Cisco and Sun don't seem to want to autonegotiate
ports correctly sometimes, especially when dealing with fiber (I recall
some issue with pause frames).
Another option is to create a special group and plot stanza for those
hosts with the problem, and set data_max to 100mb. That can all be done
in orcallator.cfg, but it results in something rather messy.
A third option is to leave data_max alone, but fake out the bit rate of
afflicted machines by multiplying it by 10. That puts them all at the
same scale as the other working servers.
> Also missing from the list seems to be nxge, which are the ports on
> all our T5240s. Do I just add that to the regex below or do I have to
> also update the orcallator.cfg used by RICHPse?
Yes, just add a regex. Be careful to follow the same pattern as the
other regex's -- parens and |'s and whatnot. I think in your case it
would look like this:
data 1024 * 8 *
((?:*(?:nxge)*|(?:bge)|(?:ce)|(?:fjg[ei])|(?:v?ge)|(?:skge)|(?:e1000g)|(?:ipge)|(?:bnx))\d+)InKB/s
I'd modify both files. The Orca server needs to know how to present the
data, and the RICHPse running on the T5240s needs to know to collect the
data. Though I didn't think RICHPse even used orcallator.cfg... I
thought it only used orcallator.se. O.o
> # Interface bits per second for 1 Gbit interfaces.
> plot {
> title %g Interface Bits Per Second: $1
> source orcallator
> data 1024 * 8 *
> ((?:(?:bge)|(?:ce)|(?:fjg[ei])|(?:v?ge)|(?:skge)|(?:e1000g)|(?:ipge)|(?:bnx))\d+)InKB/s
> data 1024 * 8 * $1OuKB/s
> line_type area
> line_type line1
> legend Input
> legend Output
> y_legend Bits/s
> data_min 0
> data_max 1000000000
> href
> http://www.orcaware.com/orca/docs/orcallator.html#interface_bits_per_second
> }
>
--
--Dragon
"draco nemo omnibus horis sapit"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/orca-users/attachments/20090821/0c16e6f5/attachment.html>
More information about the Orca-users
mailing list