[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