[mrtg] Re: How to read data accurately from Accton 3512A and 3524A??

[Alex van den Bogaerdt]

Ming Fong Lei wrote:

> You can see the our measurements at http://ipserver.ee.ntu.edu.tw/data.html

I can't.  Apart from getting quite an amount of packet loss, the
server (or a router along the path) denies the connection.

> From 1630 to 1700 hour, I was receiving several large files (3~4 Gb) from a
> FTP outside our campus, the reading from my FTP client software is
> ~2800kbyte/s, however the reading from mrtg during this period of time is
> only about 2300kbit/s.  Apparently there is something wrong which either the
> agent itself or the MRTG program.  I've checked the data flow with the
> software provided with the hub, and it is correct.  So it must be with the
> way my MRTG is set up.

2800 kBps and a 5-minute polling interval means the counter will increase
by 2800000 * 300 = 840000000 bytes.  This is less than 4294967296 so that
shouldn't impose a problem.  The data transfer must have lasted at least
20 minutes so at least three MRTG intervals have been used entirely.

Two things to do:

1) Find a way to get the interface counter values by other means,
   preferably both by using SNMP and by *not* using SNMP
2) do another test, this time comparing the several data sources:
   -a- take the following counters
      i) top of the log file, just after mrtg has run
     ii) counters using SNMP
    iii) counters from another source (i.e. device command line)
   -b- wait until mrtg runs again, then fetch the same counters again.

MRTG calculates the rate by doing the following:

   [current counter value]  -  [previous counter value]
  ------------------------------------------------------
  [current time in seconds] - [previous time in seconds]

You can do the same and compare to see what fails.

If there's other traffic on the link the data rate may have been
~ 15 MBps (assuming your link can handle this).  If so, the counters
increase with 300 * 15 MBps = 4.5 GB.  This is more than what a
32-bit counter can handle; the counter wraps within one polling
interval and MRTG "thinks" there has been an increase of 4.5 G - 2^32.
This increase when divided by 300 seconds to get Bps is in the kB range.

To solve this kind of problem: use 64-bit counters, see the archives.

HTH
-- 
   __________________________________________________________________
 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
+----------------------------------------------------------------------+
| Technical questions sent directly to me will be nuked. Use the list. | 
+----------------------------------------------------------------------+
| http://faq.mrtg.org/                                                 |
| http://rrdtool.eu.org  --> tutorial                                  |
+----------------------------------------------------------------------+

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi