[mrtg] Time drift in entries in log file.

[Stuart Kendrick]

hi ayaz,

i'm not tracking the difference between lines 1, 2, 3, and 4 ... i have, 
in fact, never looked at an MRTG log file ... i use RRD databases instead

so, with that caveat in mind, take my further comments with as much salt 
as you see necessary

 > The MRTG is set up, in my environment, in a local LAN settings and 
should
 > like to believe that there are no apparent delays in anything and no
 > perceptible network load, either.

here's what i think i know about this subject:

*i suspect that both your MRTG host and the MRTG target (SNMP agent ... 
the thing you are polling) run multi-job operating systems, meaning that 
they run multiple processes at a time, each one competing for one CPU 
(maybe they have multiple CPUs ... but in any case, fewer CPUs than 
runnable processes)

*so, when your MRTG process wants to emit an SNMP GET to the target ... 
it must wait its turn, competing with other processes on your MRTG host. 
  this wait period introduces jitter between when your MRTG applications 
wants to emit the SNMP GET and when the box actually emits the GET

*you are saying that your network is small, with countably few devices 
(perhaps only one) between your MRTG host and your target ... and that 
this network sees low levels of traffic, i.e. short or perhaps 
non-existent packet queues at the egress ports of your switches and 
routers.  sure, i buy this.  for the sake of argument, let's say that 
your network introduces 0 latency and (and thus 0 jitter) into this 
transaction

*your target is running multiple processes, and when the SNMP GET from 
your MRTG host arrives, the TCP/IP stack on your target must receive and 
process the GET and then hand that GET to the SNMP agent.  all this 
requires CPU attention, meaning that all this requires competing with 
other processes.  if the CPU is idle when the GET arrives, things happen 
fast.  but if it is busy doing something else ... then more delay.  once 
the GET reaches the SNMP agent, the agent must look up the response. 
perhaps this is easy (perhaps the target maintains the answer in some 
pre-populated table, at which point the target performs a look-up on a 
table in memory to get the answer).  but perhaps the target must perform 
some calculation before producing the answer.  in any case, the SNMP 
agent must compete with other processes for CPU time

*and of course, this whole dance is repeated as the response crawls its 
way back to the MRTG application on the host

*and once the answer actually reaches MRTG on the host, MRTG must 
perform a disk read on the relevant file.  perform a calculation.  and 
perform a disk write (or perhaps more than one write) to store the 
result.  if the disk is busy servicing other requests ... the MRTG 
process must wait


i'm not claiming that this is what is happening in your environment. 
i'm not sure how i would prove that this happening in your environment 
(or in mine, for that matter).  all i'm saying is:  i'm unimpressed by a 
jitter of 2-4 seconds in a complex, periodic task like this.  there are 
so many places for delay:  on the client, on the server, and on the 
network (though, in this case, i'm willing to buy the idea that delay on 
the network is effectively zero)

my two bits ...

--sk

stuart kendrick
fhcrc

Ayaz Ahmed Khan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> "Steve Shipway" typed:
>> "Ayaz Ahmed Khan" wrote:
>>> I have setup MRTG on a system at work.  In the log file generated and
>>> subsequently updated by MRTG, I am seeing a time drift of anywhere
>>> from 2, 3 to 4 seconds in lines 2 to 4, despite MRTG being set to poll
>>> every five
>> I don't think this is a cause for concern.  Polling will often take
>> varying times as it depends on server and network loading.  However,
>> MRTG compensates for this by adjusting its internal rates based on the
>> data logging times, so if the poll happens a few seconds late, then the
>> rate of change will be very slightly adjusted to reflect this.  If you
>> use gauge, though, I think the numbers may be logged as-is to the data
>> time window.
> 
> The drift is in lines 2 and lines 3 only.  The rest of the lines vary by an 
> absolute number of seconds, which is 300 seconds in my case.  
> 
> I'm writing a Perl script that retrieves traffic data and time from the log 
> file every five minutes (or more, depending on how long the script takes to 
> reach the point where the function that parses the mrtg log file is called), 
> and I'm required to return values for those lines in the log file where the 
> timestamp matches a defined criteria and is a multiple of 300 [seconds].  
> Only lines 2 and 3 are showing an inexplicable drift of 2, sometimes 3, or 4 
> seconds, which is adjusted by MRTG in the next run but the new values 
> introduced in place of lines 2 and 3 have a similar drift again (which is 
> again adjusted on the next run and so on).  I am, right now, achieving what 
> is required by ignoring lines 1-3.  This seems to work perfectly, but I am 
> curious why the drift is there, and whether it is something that can be seen 
> anywhere where MRTG is deployed or it is valid only in my case and for my 
> setup.
> 
> The MRTG is set up, in my environment, in a local LAN settings and I should 
> like to believe that there are no apparent delays in anything and no 
> perceptible network load, either.
> 
> Thank you for replying, Steve and Stuart.  Your replies are much appreciated.
> 
> - -- 
> Ayaz Ahmed Khan
> 
> Falling in love makes smoking pot all day look like the ultimate in
> restraint.
>                 -- Dave Sim, author of "Cerebus".
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> 
> iQEVAwUBRfzsigFi6bOwa2ADAQKTCAf+JTVIrSXK/Dmkrjn/mlsKsyERoPxYYK5n
> 4kfd0hbc72acDodlZF0SczRsbMbKdIU5l8NElbZdNuMCH7ofRncDqHOSYwCDUH61
> vfdsqE4R1rnszJCARJ075P0tWZhp5Z7nG/QWlr+AxTwhER9fZU54wYTFls4daX86
> sHnPtfTIUwusrSLeWqxf+31RiInsBMZkhNbS9ZaVPNa79MA0Jw9xFZgMcjnkiKeH
> wCVdhtCO9sQxqJ1GtOZ1mVjK68F/VL2JCcOYKvDkvzJ7j56fvnn5zCpj6e57NCoO
> THpOHD5nFctWtSQwKNxv8Dszbx8MLb5GWK2MF0v6NFFKYxf8AArGbA==
> =vwc9
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> mrtg mailing list
> mrtg at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/mrtg