[mrtg] Re: MaxBytes question

[Shahira Rasmy]

 your log file is so logic don't panic.

> 1) there are two lines with the same timestamp.
this is because the first line in any log file expresses the value read from
the buffer counter as it is i.e. the accumulated value
the second line,gives the values resulted after averaging on the interval (5
min. in our case).

> 2) on one line, the 3rd and 4th column have dissappeared.
The 3rd and 4th columns expresses the max reading in a given interval,so it
has no sense to be found in the first line,as the first line is the actual
reading as mentioned.

> 3) the 3rd column is 3 times bigger than the 2nd column. It was just a
> download, so there is of course returntraffic going back
> (acknowledgements), but that should not be AFAIK about 1/3 of the
> download
depending on the previous points you can find the second column (expressing
the upload) is around 1/3 the reading of the first column (expressing the
download).Whereas you can't compare with the 3rd and the 4th columns as they
express the max as mentioned.

I hope this explanation may help u,
c u soon,


----- Original Message -----
From: "richard lucassen" <mailinglists at lucassen.org>
To: <mrtg at list.ee.ethz.ch>
Sent: Wednesday, March 05, 2003 5:19 PM
Subject: [mrtg] Re: MaxBytes question


> On Wed, 5 Mar 2003 16:17:36 +0200
> "Shahira Rasmy" <srasmy at nile-online.net> wrote:
>
> > Dear Richard,
> > You are most probably using the option,
> > Option[]:unknaszero in your cfg file.
> > Thsi option make the values exceeding the MaxBytes to be graphed as
> > zero. While without this option the graph saturates on the last value.
> > I think it's useful to make sure that this option is not found in any
> > part of your cfg file.
>
> Hmmm, this is what happens in the logfile. When I do a download greater
> than the MaxBytes, strange things happen:
>
> 1) there are two lines with the same timestamp.
> 2) on one line, the 3rd and 4th column have dissappeared.
> 3) the 3rd column is 3 times bigger than the 2nd column. It was just a
> download, so there is of course returntraffic going back
> (acknowledgements), but that should not be AFAIK about 1/3 of the
> download
>
> 1046877004 1275209237 3239266009
> 1046877004 1761 167 1761 167
> 1046876704 37847 19265 37847 19265
> 1046876700 37847 19042 37847 19265
> 1046876400 37342 2577 37847 2612
> 1046876100 0 0 0 0
> 1046875800 0 0 0 0
> 1046875500 0 0 0 0
> 1046875200 0 0 0 0
> 1046874900 0 0 0 0
> 1046874600 0 0 0 0
> [snip]
>
> There is nothing about such behaviour mentioned in
> http://people.ee.ethz.ch/~oetiker/webtools/mrtg/logfile.html
>
> Do you have a hint?
>
> Richard.
>
> --
> ___________________________________________________________________
> Recursion: see recursion
>
> +------------------------------------------------------------------+
> | Richard Lucassen, Utrecht,    Linux 2.4.20 RedHat 7.2            |
> | The Netherlands               i686/1200MHz/768MB                 |
> | Public key: http://www.xs4all.nl/~pe1bbf/pubkey.asc              |
> +------------------------------------------------------------------+
>
>
> -- Binary/unsupported file stripped by Ecartis --
> -- Err : No filename to use for decode, file stripped.
> -- Type: application/pgp-signature
>
>
> --
> 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
>
>
>


--
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