I am using the tc functionality provided by iproute2 to setup classes and queueing disciplines. I have a requirement to determine the queueing delay of each packet belonging to a particular class so that i can measure the average queueing delay over a time interval for a particular traffic class. I would be grateful if somebody could give me pointers on how i possibly can achieve this. I suspect that i would have to modify the source code of iproute2 , but am not too sure on what segment of the code i should be modifying. __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com
On Tue, Feb 26, 2002 at 05:02:45PM -0800, Radhakrishnan Vijay wrote:> I am using the tc functionality provided by iproute2 > to setup classes and queueing disciplines. I have a > requirement to determine the queueing delay of each > packet belonging to a particular class so that i can > measure the average queueing delay over a time > interval for a particular traffic class. I would be > grateful if somebody could give me pointers on how i > possibly can achieve this. I suspect that i would have > to modify the source code of iproute2 , but am not too > sure on what segment of the code i should be > modifying.Right now the actual delay is not measured by the kernel, so I don''t see how you would get at it. You could calculate the effective class bandwidth and multiply that by the average qlength, but that would be pretty indirect. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
you have to modify kernel code ;) Add one field into sk_buff and initialize it with TSC at recieve. Then in global dequeue in sch_generic.c IIRC you can compute delay and either prinkt or average it directly in kernel. devik On Tue, 26 Feb 2002, Radhakrishnan Vijay wrote:> I am using the tc functionality provided by iproute2 > to setup classes and queueing disciplines. I have a > requirement to determine the queueing delay of each > packet belonging to a particular class so that i can > measure the average queueing delay over a time > interval for a particular traffic class. I would be > grateful if somebody could give me pointers on how i > possibly can achieve this. I suspect that i would have > to modify the source code of iproute2 , but am not too > sure on what segment of the code i should be > modifying.
How about this: use tcpdump to record the packets of that class match up the incoming and outgoing packets take the difference in tcp timestamps > From: Radhakrishnan Vijay <vijayr13@yahoo.com> > To: lartc@mailman.ds9a.nl > Subject: [LARTC] measuring queueing delay using iproute2 > > I am using the tc functionality provided by iproute2 > to setup classes and queueing disciplines. I have a > requirement to determine the queueing delay of each > packet belonging to a particular class so that i can > measure the average queueing delay over a time > interval for a particular traffic class. I would be > grateful if somebody could give me pointers on how i > possibly can achieve this. I suspect that i would have > to modify the source code of iproute2 , but am not too > sure on what segment of the code i should be > modifying. It won''t help to modify iproute2. It''s not doing the forwarding. It only tells the kernel what you want the kernel to do.
On Wed, Feb 27, 2002 at 08:57:11AM -0800, Don Cohen wrote:> > How about this: > use tcpdump to record the packets of that class > match up the incoming and outgoing packets > take the difference in tcp timestampsWon''t work - tcpdump sits before the packet scheduler, and not after. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
bert hubert writes: > On Wed, Feb 27, 2002 at 08:57:11AM -0800, Don Cohen wrote: > > > > How about this: > > use tcpdump to record the packets of that class > > match up the incoming and outgoing packets > > take the difference in tcp timestamps > > Won''t work - tcpdump sits before the packet scheduler, and not after. No way. For instance, the packet scheduler can decide to drop the packet. In which case it better not show up in tcpdump! Tcpdump is after dequeue, just before giving the packet to the device.