[Click] Problems in measuring delay time with CycleCountAccum

[Eddie Kohler]

Hi Alessandro,

Sorry for the delay in responding.

I think that my response to Xavier Grandmougin's recent mail will also 
apply to you, since you had a CycleCountAccum *after* the ARPQuerier.  
Here it is again:

> Hi Xavier,
>
> There are probably two things going on.
>
> (1) ARPQuerier generates ARP queries and emits them.  Since it makes 
> these packets from scratch, they have cycle count annotation = 0!  
> CycleCountAccum will do the equivalent of:
>
>       current_cycle_count = click_get_cycle_count();  /* huge: 10^8 or 
> more*/
>       _accum_difference += packet->cycle_count() - current_cycle_count;
>                                /* _accum_difference += 10^8 - 0 == 
> 10^8! */
>
> You can avoid this by supplying ARPQuerier with two outputs.  The 
> first output will be for IP-in-EThernet packets; put hte 
> CycleCountAccum there.  The second output is for ARP queries; don't 
> put CycleCountAccum there.  So for example:
>
>      querier0:: ARPQuerier(...);
>      querier0[0] -> CycleCountAccum -> queue0;
>      querier0[1] -> queue0;
>
> (2) ARPQuerier holds on to packets for a while (like a Queue), if it 
> needs to make an ARP query.  So even without (1) you'll see large 
> numbers (but not 00's of seconds).
>
> I'm going to change CycleCountAccum to ignore packets with cycle count 
> anno == 0, so that problems like (1) will be less frequent.

So you might try that 'querier0' trick, or current CVS Click, to see if 
you still get the same huge nonsense cycle counts.

Thanks,
Eddie



On Apr 14, 2004, at 3:30 AM, Alessandro Coli wrote:

>
> Hi to all. I am trying to make some performace tests on some computers 
> i have.
>
> In this moment, i am interested into the average delay time introduced 
> by the
> click router.
>
> To calculate it on the router (a dual processor Intel Xeon 2800 Mhz) i 
> placed an
> element "SetCycleCount" right after the Polldevice, and another
> "CycleCountAccum" right before the ToDevice. I had thought to run a 
> 120 seconds
> test with packets of 64 bytes and a rate largely "light" for the 
> router pc(at
> this rate there are not packet losses) and, after, to read 
> CycleCountAccum's
> handlers and then calculate delay in microseconds like this:
>
> Delay (microseconds) = (CycleCountAccum.cycles / 
> CycleCountAccum.count) / 2800
>
> And i did it. But, when i read the value of CycleCountAccum, i found 
> incredible
> high values! And, in fact, calculating the delay with the previous 
> formula, i
> got delays like 20800 microseconds!!!!
>
> This is an absolute non sense. I thought the problem might be the fact 
> i was
> doing these measures on a dual processor pc (maybe CycleCountAccum 
> does not work
> well with dual processor pcs, I thought), so i tried to use 
> SetCycleCount and
> CycleCountAccum on another pc which is a normal mono-processor pc 
> (Intel Xeon
> 2400 Mhz), to see if it was me not using these elements in the right 
> way or if
> it really was the dual processor thing (in this last case, i'd expect 
> normal
> delays in the second test i made).
>
> Unfortunately, even on the monoprocessor pc, i got the same problem. 
> Absolutely
> high and nonsense delays. Maybe i am doing something wrong? Or are 
> there some
> problems with Xeon processors? Did something similar happen to you too?
>
> Thanks
>
> Alex
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click