Hi Nilay, Yeah the Queueing delay is only updated after a packet is received. For packets waiting to be injected, the queuing delay is dynamically increasing, so it is hard to update any stat. It can only be updated at injection/receive time. At the end of the simulation we are interested in seeing the delay breakdown of received packets which is what is printed out. Average latency would simply be (network + queueing latency)/received packets. If packets that are not yet injected or are midway in the network also increment the latency stats, then the average latency formula won't make sense.
Even if we print out the queueing delay of packets waiting to be injected, that does not imply the corner case of deadlocks as the network might just be heavily congested. When these packets eventually get injected, this will get reflected by the queueing delay stats so also adding info about current waiting packets does not add any extra information. The way to identify a deadlock (which is what I did) would be to inject say a fixed number of packets using --fixed-pkts and observing that the number of received packets gets stuck at a particular value, less than the injected packets, and does not rise even if simulation time (--sim-cycles) is increased. Thanks, Tushar On Mar 21, 2012, at 10:09 PM, Nilay Vaish <[email protected]> wrote: > Tushar, queueing delay currently does not include delay for the packets that > are waiting at the network interface for being injected into the network. The > queueing delay for these packets will be very high in case of a deadlock in > the routing protocol. > > -- > Nilay > > On Tue, 20 Mar 2012, Tushar Krishna wrote: > >> Hi Nilay, Yes this is precisely the queueing delay stat. If the protocol >> generated a message at time t1, it got injected from the source NI into the >> first router at time t2, and it is received by the destination NI at time >> t2, then: queueing delay = (t2-t1) network delay = (t3-t2) >> >> The network delay and queueing stats are updated AFTER the packet is >> received. >> In the simulation you ran, since there was a deadlock, everything just >> stopped. >> If everything is received (say using a Mesh), the queueing delay will show >> up to be extremely high if the network is extremely congested/there are not >> enough buffers/VCs. >> >> cheers, >> Tushar >> >> >> On Mar 20, 2012, at 12:52 PM, Nilay Vaish wrote: >> >>> Tushar, thanks for the help. The stat that I found useful was the number of >>> packets that are waiting at network interfaces for being routed, and the >>> average time for which these packets have been waiting. I think this time >>> should be part of the queueing delay stat that is already present. What do >>> you think? >>> >>> -- >>> Nilay >>> >>> >>> On Mon, 19 Mar 2012, Tushar Krishna wrote: >>> >>>> Hi Nilay, >>>> Seems like the problem is deadlock in the Torus topology. >>>> The code enforces XY routing in the Torus (similar to a Mesh) but since >>>> there are rings in every row/column, it leads to a cyclic dependency >>>> within a dimension at high loads. >>>> Each response message becomes 5 flits increasing load in that vnet, which >>>> is why this artefact is being seen. I never tested the Torus at high-loads >>>> before so missed this. >>>> I notice that decreasing the injection rate to 0.1 does not show this >>>> problem. >>>> >>>> If you change the topology to Mesh, you will notice that all messages are >>>> received. >>>> Even in a mesh, though, you will have to decrease the injection rate, >>>> since 0.3 is post saturation. >>>> [0.3 packets/node/cycle => 0.3x(1+1+5)/3 flits/node/cycle = 0.7 >>>> flits/node/cycle. An 8x8 mesh theoretically saturates before 0.5 >>>> flits/node/cycle]. >>>> >>>> There are a bunch of deadlock free routing algorithms for torii, one of >>>> which will have to be implemented I guess for the Torus topology to be >>>> robust. >>>> Should we add a warning in that topology file about this? >>>> >>>> Thanks, >>>> Tushar >>>> PS: I am pushing a patch for review that (1) breaks the stats on a per >>>> vnet basis which is useful for such debugging etc, and (2) cleans up >>>> redundant code between flexible and fixed networks. >>>> >>>> >>>> On 03/18/2012 06:41 PM, Nilay Vaish wrote: >>>>> Tushar >>>>> I am using the network tester in gem5 with GARNET. I am observing a >>>>> peculiar behavior when I run the following command -- >>>>> ./build/X86/gem5.fast ./configs/example/ruby_network_test.py >>>>> --num-cpus=64 --num-dirs=64 --topology=Torus --garnet-network=flexible >>>>> --mesh-rows=8 --sim-cycles=10000 -i 0.30 --random_seed=1 >>>>> As you might recall, there three different types of messages generated by >>>>> the network tester -- request, forward and response, and these are >>>>> generated with ration 1:1:1. In the file ruby.stats, the number of >>>>> responses that reach the directory controllers are way less than compared >>>>> to the number of requests and forwards, the ratio being >>>>> 10(request):10(forward):1(response) . It seems that the network interface >>>>> at the cache controller is not able to issue most of the response >>>>> messages and hence these keep waiting the in the queue at the input port. >>>>> Can you look into why this is happening? >>>>> Thanks >>>>> Nilay >>>> >> >> _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
