[Click] Measuring

[Egi, Norbert]

>just one thing: are you going to measure the
>packet's delay/jitter inside your click configuration
>or the global delay/jitter from the packet source to the
>receiver ?

 
I want to measure the global delay/jitter from the packet generator to the receiver, which is the more complicated thing.

>In the first case, the CycleCount elements can help you
>(you can also modify the CycleCountAccum to collect the single delay of each
>packet in a table - but that table cannot be too large,
>bacause the kernel memory space is limited).

>In the second case, you could
>- sincronize the packet source and receiver with
>some tool, but this could be helpful if you are interested
>in an averaged measurement, usually this way doesn't
>conduct to extreme precise measurements
>- use the source as a receiver at the same time, inserting
>a timestamp inside the packets, but...
>you can't inject packets too fast, not only because the CPU
>would be overloaded but also because your generated/received packets
>would interfere with themselfs
>(remember that the PCI bus and memory are shared structures).

 
I have already thought about these issues. It would be good to use Click for measuring the delay/jitter as well besides the packet rate and loss, but I think at first I will try out some other tools including the ones that were suggested by Laercio and only if they don't work the way I want I will try to create some click elements for global delay measurements.

>If you are interested, I described an analysis of these problems
>here:
>
>http://www.read.cs.ucla.edu/click/publications
>
>Software techniques for multiservice IP networks.
>Giorgio Calarco. Ph.D. thesis, University of Bologna, Italy
>
>at Chapter II.

 
I'll check out the relating chapter of your thesis.
 
Thanks,
Norbert