[mrtg] some help!

[Alex van den Bogaerdt]

----- Original Message ----- 
From: ""Rafael M. Carballosa Hernández"" <rafael.carballosa at etecsa.cu>
To: <mrtg at lists.oetiker.ch>
Sent: Wednesday, May 27, 2015 7:08 PM
Subject: [mrtg] some help!


>
> We have been working on information generated by mrtg, taking results of
> pooling process  (log al old archives) and graphics generated by mrtg,
> just information about bandwidth consumption.
> Mainly, we use those datas to introduce them into postgres database and
> letexternal users to perform different types of queries through a website.
> We are having problems with the calculation of bandwidth. On several
> occasions the percentage of occupation is going above 100%. I know that
> this is impossible, I have verified with the service provider and
> bandwidth is correct, I make calculations speed as logic says (calculate
> the difference of bytes in the number of seconds elapsed and express
> them in bits/sec). I am writing to you to know if you have had this
> experience and help me find the solution.
> An example: An user connected with adsl,  download bandwidth of 6400
> Kbps, register speed of 6500, 6800 Kbps in high traffic peaks.


Things to check:

kilo==1000 and mega==1000kilo.
some people think it should be 1024 in either, or both, cases.
The error could be 1.024 x 1.024 = 1.048576 which comes close to 6800/6500.

Timing is critical. Delay in itself isn't even a big problem, as long as the 
delay is constant. If there is some variable delay introduced while 
measuring (busy server, much swapping going on perhaps), then some of the 
bytes end up in the wrong interval: one interval contains too many and the 
next or the previous contain too little.  Example by numbers: if the actual 
interval being measured is 62 seconds but MRTG thinks it is 60 seconds, then 
at a rate of 6,500,000 bits per second, 62/60 x 6500000 = 6716666.66... is 
reported.

How hard is the limit? My provider promises 3Mbps up and 30Mbps down but in 
reality they provide a bit more.

There will be more to check. Others will reply as well.