Hi all, I have a setup with 3 hosts connected like this: purcell (eth1) <-> (eth2) mozart (eth1) <-> (eth2) kodaly
On Mozart, I have this very simple click configuration running with the latest click code (userlevel) from GIT today: FromDevice(eth2, PROMISC 1) -> C1 :: Counter -> Q1 :: Queue(10) -> BandwidthShaper(250000) -> ToDevice(eth1); FromDevice(eth1, PROMISC 1) -> C2 :: Counter -> Q2 :: Queue(10) -> BandwidthShaper(250000) -> ToDevice(eth2); On Kodaly, I use Rude to send 1020 packets/s with a payload of 512 B/packet during 3s, which should result in a stream of 4.5 Mbps. As BandwidthShaper is configured to shape the incoming traffic to an outgoing flow of 2 Mbps, one should expect a loss rate of +/- 50 %, or at least a full queue after 20 ms. However, when I run this simulation using a script that just starts the stream, waits 1s and prints out the appropriate element handlers, I get following results: $ sh clicktest.sh 10 run 1: 0 packets dropped out of 1607 = 0 % packet loss run 2: 0 packets dropped out of 2001 = 0 % packet loss run 3: 0 packets dropped out of 1995 = 0 % packet loss run 4: 0 packets dropped out of 1995 = 0 % packet loss run 5: 0 packets dropped out of 1996 = 0 % packet loss run 6: 0 packets dropped out of 1543 = 0 % packet loss run 7: 0 packets dropped out of 1997 = 0 % packet loss run 8: 0 packets dropped out of 1995 = 0 % packet loss run 9: 0 packets dropped out of 1990 = 0 % packet loss run 10: 0 packets dropped out of 2001 = 0 % packet loss Highwaterlevel_length at each queue returns just 1, which seems very strange to me. When I check on Mozart all incoming and outgoing packets with tcpdump, the packets arriving from Kodaly correctly are correct: 3062 packets at +/- 4.5 Mbps constantly. However, a tcpdump on the outgoing interface tells me 1872 packets are sent out: - from 0 to 0.6 s at +/- 4.5 Mbps - from 0.6 s to 3.3 s at +/- 2 Mbps Weird, doesn't it? FWIW: all 3 machines are identical and run Fedora Core 9 with kernel 2.6.25.14-108.fc9.i686. The used network cards are Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10). Does anyone have an idea about what't wrong here? Thanks a lot! Kind Regards, Peter -- ir. Peter Dedecker IBCN Research Group Department of Information Technology (INTEC) Ghent University - IBBT Gaston Crommenlaan 8 bus 201, B-9050 Gent Tel: +32(0)9 3314977, Fax: +32(0)9 2649969 [email protected] _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
