[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ds patches for statistics




Giacomo,

I took a quick look. comments below:
              
- Do you have any numbers/findings you would like to share ?


On Thu, 4 Nov 1999, Sergio wrote:

> Hi,
> to test the performances of a Linux Diffserv router (Linux 2.2.10+DS6)
> we have implemented new statistics  taken from the kernel for the tc:
> -queuedelay is the internal queueing delay experienced by packets;
> -rate is the outgoing packets rate.
> We have used the function  do_gettimeofday to take the sk_buff stamp so
> that we have better precision and resolution.
> I have attached the patches for linux-2.2.10 and tc.


- it is a bad idea to use the general skb->stamp in case
some other code (from ingress towards egress) uses it. why dont you create
your own variable on the skb?

- the rate measurement: You need to use some averaging algorithm (look at
the policer code) to average over long periods of time. In your scheme,
the "last valid b/w utilization" will be reported. Think of a situation
where you have a long period of inactivity (i.e no packet arrivals); you
invoke tc and it instead reports the last one stored in the kernel.

- could your tables in the kernel be overwritten at some point with some
invalid data? eg in the situation where there are long periods of
idleness.

- In your scheme, you have to change every qdisc that you want to 
participate in the "profiling". You might want to sync with Ole Husgaard
<sparre@login.dknet.dk> -- i am not sure if he is on this mailing list ...
Ole has a nice scheme with a classful qdisc which you "wrap around" a
qdisc that you want to "profile". I dont think he had the concept of
profiling rates and latencies, this is something you could add. His was
more sort of a tcpdump/sniffer-tracer for qdiscs. i.e it would show you
traces of the path that a packet takes as it wiggles its way through the 
qdisc membrane.

Ole, if you are on the list, care to provide a dump?

cheers,
jamal