Hello Simone, you should be referring to the 'stamp_updated' field. It tells you when the record has been "touched" for the last time. Such minor delays could appear for a variety of reasons, including:
* It is a cumulative delay while dealing with a remote SQL server. * The old tale of 'lazy' refresh times. The story behind it: once in the times (and they were really OLD times, Wim Kerkhoff was still using MySQL !!) pmacct was used to handle refresh time deadlines the 'hard' way: by setting timers via syscall and getting kicked by the kernel (via SIGALRM) each expiration. Disturbing the kernel too much is never a good rule, expecially when it's assumed to be already busy delivering you the amount of packets captured from the network ! So, we switched to 'soft' (or 'lazy') refresh times: captured packets make pmacct rolling; why not being savy and take advantage of such rolling to handle (set and check) refresh time deadlines ? The method is then 'protected' by a timeout value which is equal to the refresh time value which make it working smoothly even on 'mute' networks (a quite common situation in lab/test environments). At this propo, remember also my last email: a correct value for refresh time should not be too little. As a general rule, it should be kept >= 30 secs. Cheers, Paolo
