[Click] Problems in measuring delay time with CycleCountAccum

[Alex Newman]

Isn't the default kernel granularity on intel machines like 20 miliseconds. If
this is the problem if you are using freebsd just set options HZ=. I was told
this is popular in Linux also. This is just a shot in the dark, I just saw 
20 miliseconds and was thinking that might be it.

This is from the FreeBSD Lint File
# CLOCK OPTIONS

# The granularity of operation is controlled by the kernel option HZ whose
# default value (100) means a granularity of 10ms (1s/HZ).
# Some subsystems, such as DUMMYNET or DEVICE_POLLING, might benefit from
# a smaller granularity such as 1ms or less.
# Consider, however, that reducing the granularity too much might
# cause excessive overhead in clock interrupt processing,
# potentially causing ticks to be missed and thus actually reducing
# the accuracy of operation.

options         HZ=100


> 
> 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
> 
> 
> !DSPAM:4083c66b314261504113533!
> 
> 

-- 
Alex Newman         INELUCTABLE MODALITY OF THE VISIBLE: AT LEAST THAT IF NO 
dolemite@/.wuli.nu  more, through my eyes. J.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : https://amsterdam.lcs.mit.edu/pipermail/click/attachments/20040419/893b8f27/attachment.bin