Sahan, I wonder whether the bug you saw here may have been due to the bug fixed here:
http://www.read.cs.ucla.edu/gitweb?p=click;a=commit;h=01c8f4e084036338e83a6bff7a8e74dc49caa014 Does the bug still occur with current sources? E Sahan Gamage wrote: > Hi Cliff, > > thanks for the reply. > Yes I am running the latest sources. > I tried following 2 configurations : > InfiniteSource(LENGTH 1000) -> EtherEncap(0x0800, 00:11:43:58:19:D1, > 00:11:43:58:19:D1) -> Queue(2000) -> ToDevice(eth1); > and > InfiniteSource(LENGTH 1000) -> EtherEncap(0x0800, 00:11:43:58:19:D1, > 00:11:43:58:19:D1) -> DelayUnqueue(0.005s) -> Queue(2000) -> > ToDevice(eth1); > > Other than click trying to occupy 100% of the CPU nothing special > happened. Also I didn't see the "BUG! Tx Ring full when queue awake!" > thing showing up. > > I am still trying to figure out what causes the actual problem. > > Thanks > -sahan > > On Thu, Jan 21, 2010 at 6:42 PM, Cliff Frey <[email protected]> wrote: >> Without knowing anything for sure, I suspect that your ethernet driver has a >> bug in the transmit side when transmitting traffic faster than the wire >> rate. >> You could try a configuration like >> InfiniteSource(LENGTH 1000) -> EtherEncap(...) -> Queue -> ToDevice; >> and I imagine that you would see the same behavior. >> You could also try plugging eth0 into a slower ethernet connection (10 or >> 100Mbps) and you might see the same behavior. >> Are you running the most recent click sources (from git)? There might have >> been some ToDevice changes since then... >> In any case, just my random ideas... I doubt that LinkUnqueue or Queue are >> actually misbehaving. >> Cliff >> >> On Thu, Jan 21, 2010 at 2:07 PM, Sahan Gamage <[email protected]> wrote: >>> Hi All, >>> >>> I was working with click router to implement a delay inducing network. >>> What I wanted was to configure a click router with standard routing >>> components and once the routing is done, add some extra delay >>> (specified). So I modified the fake-router.click to include real >>> network devices (which is much similar to the router discussed in SOSP >>> 99 paper). I encountered two problems. >>> 1. When I ran the router without delay elements and use an iperf >>> client and server on the two sides of the router, the maximum >>> throughput I got was 330Mbps. The network drivers were tg3 drivers. My >>> feeling is that the throughput is somewhat lower than that is >>> expected. >>> >>> 2. Then I changed the configuration a little bit to introduce delays. >>> What I did was change the output component from: >>> out0 :: Queue(2000) -> ToDevice(eth0) >>> to >>> out0 :: Queue(2000) -> LinkUnqueue(0.005s, 1000Mbps) -> Queue(2000) -> >>> ToDevice(eth0). >>> >>> I did this for both eth0 and eth1. >>> But when I ran this configuration, the machine always locks up. >>> Sometimes I can see there's a log entry in kernel message log saying >>> "tg3: eth1: BUG! Tx Ring full when queue awake!". Few options I >>> tried : >>> - I tried different delay elements such as LinkUnqueue and DelayUnqueue. >>> - I tried different Queue sizes (from 200 to 5000). >>> - I changed the Tx ring size of the devices to 511 (maximum allowed). >>> >>> But none of them resolved the problem. >>> >>> My feeling is the crash (or the lockup) is primarily due to the delay >>> introducing elements (LinkUnqueue or DelayUnqueue). Does anybody know >>> the reasons for reduced performance numbers and the lockups ? >>> >>> (I have attached my configuration file along with this) >>> >>> Thanks in advance >>> -sahan >>> >>> _______________________________________________ >>> click mailing list >>> [email protected] >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >> > > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
