[Orca-users] Re: Problem with the "Interface bits per second" calculation code ???

[Blair Zajac]

Hi Sean,

Which version of SE and orcallator.se are you using?

Orcallator.se just relies on the SE network interface code to generate
these statistics, so that's the place to begin looking.

I vaguely recall hearing some issues like this and I believe they were
fixed in SE at some point.  If you don't have the latest SE, then I'd
upgrade to that version.  Get the latest SE and its patches at

    http://www.setoolkit.com

Also, it would be interesting to run some of the SE supplied example
programs that monitor network bandwidth to verify that its not
orcallator.se.  Run RICHPse/examples/nx.se and if you see the same
problem, then the problem is definitely with SE.

Regards,
Blair

sean.oneill at appnet.com wrote:
> 
> I have found a potential problem with the "Interface bits per second"
> calculation code ... I think.  The reason I think there is a problem
> is because I have MRTG and ORCA watching a specific system.  The MRTG
> graphs do not show the potential problem behavior that the ORCA chart
> does for this specific piece of information.
> 
> Specifically, it appears the ORCA code (or the SETool code - not sure
> which one) doesn't handle an interface counter rollover gracefully.
> We have a network which has a constant 2Mbit multicast stream going
> across it so the interface counters accumulates very rapidly.  The
> ORCA graph for this interfaces shows:
> 
> 1) A steady 2Mbit/sec graph for several hours (usually 5 to 6).
> 2) It then drops to 0Mbit/sec for 15 to 45 minutes.
> 3) It starts graphing again with a single 5-minute spike of 6 to
> 9Mbit/sec which is followed by the usual 2Mbit/sec trend.
> 
> I'm almost positive this is a counter issue because at times the
> multicast traffic can drop to 1Mbit/sec.  In this case, the time to
> the next problem behavior is 10 to 12 hours - twice as long.
> 
> Is this a known issue or something new?
> 
> Sean O'Neill