Re: [pmacct-discussion] reloading config & accuracy

[Tony]

Hi Paolo,

--- On Mon, 7/9/09, Paolo Lucente <pa...@pmacct.net> wrote:

> From: Paolo Lucente <pa...@pmacct.net>
> Subject: Re: [pmacct-discussion] reloading config & accuracy
> To: "Tony" <td_mi...@yahoo.com>
> Cc: pmacct-discussion@pmacct.net
> Received: Monday, 7 September, 2009, 2:28 AM
> Hi Tony,
> 
> On Sat, Sep 05, 2009 at 09:01:01PM -0700, Tony wrote:
> 
> > I have tested the above suggested configuration and it
> is working. There is data going into the SQL table now! I am
> going to let it run in parallel with the unadjusted data
> (which is going into another table) and then compare the two
> of them and also compare to the stats being reported by the
> packeteer.
> 
> I've just managed to commit to the CVS repository some
> code to remove a dependency between actions and checks
> in the sql_preprocess layer (so that you can roll-back
> to your original config, which did make sense). I also
> went through an overall review of the feature - which
> resulted in a couple of fixes (one right to the 'adjb'
> section) and some cleanups. 
> 
> Hence I would highly invite you to make your assessment
> against the version currently in the CVS or alternatively
> wait until the rc2 release is out, later in the week.
> 


I haven't upgraded yet, I will be doing that now, but I wanted to give you some 
feedback on what I'm seeing in the old version and we can see if it persists to 
the new version.

The line I have added to the config file is:

sql_preprocess[abc]: minp=1, adjb=26

I am not sure how it is applying the extra though as it is only making a small 
difference.

I am using 10 minute aggregation and an example of data for a single IP address 
is:


10306644        10306462        182     0.00177%
83631880        83631698        182     0.00022%
1016473         1016265         208     0.02047%
3318523         3318341         182     0.00548%
48220490        48220308        182     0.00038%

The first number is the value (bytes) in the adjusted table, the second is the 
unadjusted/original number (bytes), the third is the difference between the two 
and the fourth is the difference as a percentage. The difference column is 
ALWAYS 182 or 208 across the whole data range that I checked.

These were retrieve using a query like:

mysql> select ip_dst, bytes, stamp_inserted from internet where ip_dst like  
'x.x.x.x' and stamp_inserted like '2009-09-18%' order by 3;

You can see that the adjustment isn't mkaing much difference and certainly not 
what I would expect to see if it was adding 26 bytes to each PACKET (which is 
what needs to be done to account for ethernet overhead).

This suggests to me that the "adjb" value isn't applied to each packet, but to 
only 7 or 8 of the packets or flows.

I just thought I'd alert you to the above and see if the changes you have 
committed make a difference. Hopefully I will be able to report back again in a 
few days.


Thanks,
Tony.


      
__________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/

_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists