[Click] AverageCounter bug

[Roman Chertov]

Egi, Norbert wrote:
> Hi,
>  
> Have you recognized after you patched the averagecounter.cc that if you divide the number of arrived packets (/proc/click/ctr/count) by the rate (/proc/click/ctr/rate) then you get an integer number all the times, which I think it's not very realistic?  I think this is because of the line 'd /= CLICK_HZ;' you added to the code. As a consequence, this makes the counter quite inaccurate, especially at high pps rates.
>  
> I made a tiny modification to your patch (attached to this email), check it out, this isn't the perfect solution either, but more accurate. Actually its accuracy is +-(CLICK_HZ) which was at my machine 250, but I'm not sure from where it comes from and whether it is the same all the time.

You are correct.  Your modification produces more accurate rate
computation.  So do you now have consistent data rates on your NICs
after this fix?

Roman

>  
> Norbert
> 
> ________________________________
> 
> From: click-bounces at pdos.csail.mit.edu on behalf of rchertov at purdue.edu
> Sent: Thu 1/4/2007 22:34
> To: click at pdos.csail.mit.edu
> Subject: Re: [Click] AverageCounter bug
> 
> 
> 
> I forgot the division by zero check in the previous patch.  The attached patch
> handles that case.
> 
> Roman
> 
> Quoting rchertov at purdue.edu:
> 
>> Hello,
>>    I noticed a bug with the AverageCounter when it would not report correct
>> rates.  This usually would happen at GigE speeds when at least 10 million
>> packets are sent.  The reported result would be much smaller than the actual
>> true rate.  I have attached a fix that fixes the problem.  Previously I
>> would
>> get numbers that would sort of wrap around.
>>
>> E.X
>> more /click/ctr/rate
>> 600000
>> more /click/ctr/rate
>> 50000
>> more /click/ctr/rate
>> 23000
>> more /click/ctr/rate
>> 500000
>>
>> Now, it turns out that I can send 1.5 million pps from one card to another on
>> my
>> machine.  I have also tested this fix for a variety of rates from udpgen and
>> the
>> reported rates from the counter are close to the desired rate.  Also at very
>> high rates UDPGen can be off by as much as 50Kpps from the desired rate.
>>
>> Roman Chertov
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: averagecounter.cc
> ===================================================================
> RCS file: /cvs/click/release/one/elements/standard/averagecounter.cc,v
> retrieving revision 1.16
> diff -u -r1.16 averagecounter.cc
> --- averagecounter.cc	9 Jan 2006 19:03:42 -0000	1.16
> +++ averagecounter.cc	4 Jan 2007 21:26:45 -0000
> @@ -81,10 +81,11 @@
>  averagecounter_read_rate_handler(Element *e, void *)
>  {
>    AverageCounter *c = (AverageCounter *)e;
> -  int d = c->last() - c->first();
> +  uint32_t d = c->last() - c->first();
>    d -= c->ignore();
>    if (d < 1) d = 1;
> -  int rate = c->count() * CLICK_HZ / d;
> +  uint32_t rate = c->count() / d;
> +  rate *= CLICK_HZ;
>    return String(rate);
>  }
>