Hi again, Not really shure here..
daemonize: false aggregate: src_as, dst_as plugin_buffer_size: 2048 nfacctd_port: zzzz nfacctd_ip: xx.yy.zz.xx ! nfacctd_time_secs: true ! nfacctd_time_new: true plugins: memory I dont use any sql right now, And I get the negativer results when doing this. pmacct -c dst_as -N xxxx -r ; sleep 300 ;pmacct -c dst_as -N xxxx -r ; sleep 300; pmacct -c dst_as -N xxxx -r -1458316866 -170266441 -445279125 /Tobias -----Ursprungligt meddelande----- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Paolo Lucente Skickat: den 21 mars 2005 11:37 Till: [email protected] Ämne: Re: [pmacct-discussion] Counter size Hey Tobias, On Mon, Mar 21, 2005 at 09:59:53AM +0100, Tobias Bengtsson wrote: > I wonder how big the byte counter can be, because I have problems with > negative counter values.. On pmacct side (that is, we are talking about the cache in the SQL plugin) counters are 32 bit (at this propo, anyone has either an opinion or comments about the topic 'u_int64_t & portability' ?); they need to accomodate counters just for a single 'sql_refresh_time' timeframe. They work the following way: when the counter is about to hit the upper 32 bit burden, it's 'archived' and a new counter is started. The next purging event (that is, when the cache is purged) the actual counter and the archived ones are framed in distinct SQL queries (and rewritten as long unsigned integers - %lu). Said this all, the negative counters should be generated by the DB. It could be matter of just enlarge the field to some more bytes. With such volumes, did you enable 'sql_history' ? By framing counters in fixed timeslots (say, 5-10 minutes or even 1 hour), you will be able to push a reliable upper burden to the growth of the counters into the DB. Cheers, Paolo _______________________________________________ pmacct-discussion mailing list [email protected] http://muffin.area.ba.cnr.it/mailman/listinfo/pmacct-discussion
