Queuing disciplines in linux kernel
From: Shrikrishna Khare
Date: Thu Apr 24 2008 - 13:06:03 EST
Hi All,
I have implemented a new queuing discipline in Linux kernel (as module
in net/sched) and I want to test that. However, no matter what kind of
network flows I run, the queue size never seems to build up even with
default pfifo implementation. Here are the things that I tried.
1. Machine A and B connected using Ethernet.
Interface configured to run at 100Mbps.
Queuing discipline configured: pfifo (default)
UDP flow from sender A to receiver B.
Result: Queue size never builds up. Any queued packet is
immediately dequeued!
Thus, I tried configuring ethernet to run at 10 Mbps with rest of
the setup same as above. Now lesser number of packet gets transferred
in same duration but the queue at sender still DOES NOT build up.
Could anyone please tell me why this happens? How do I test my
queueuing discipline implementation then?
I tried another thing:
2.
Machine A connected to machine B over ethernet configured to run at
100 Mbps
- Machine B connected to machine C over ethernet configured to run at
10 Mbps
- When I run iperf flow from machine A to machine C, I expected
congestion to occur at machine B since its being fed by 100 Mbps link
while data can go out only at 10 Mbps. Thus, I expected the queue size
(printed from pfifo queue in net/sched/sch_generic.c code) to grow.
But it NEVER seems to grow. Machine A to C connection seems to get
bandwidth of only 10 Mbps.
When I trace using dmesg, all I see is sequqnce of alternate Enqueue
and dequeue operations and hence the queue never grows.
Could anyone please provide me with any pointer as to why this
happens? How to test queuing disciplines then?
Thanks and Regards,
Shrikrishna
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html