Understood. Thank you very much Tushar, Bye.
On Fri, Jul 5, 2019 at 2:45 PM Krishna, Tushar <[email protected]> wrote: > But, flit latency keeps growing unbounded as I increase the injection rate > (as if buffer was infinite). > > Good question. The buffers are finite everywhere except at the traffic > generator (src/cpu/testers/GarnetSyntheticTraffic/). > The traffic generator keeps creating new packets at the user-specified > injection rate. But the rate of their injection into the network of course > gets saturated. So the latency shoots up because the “queueing latency” > factor keeps growing while the “network latency” component saturates. You > can see this phenomenon in the stats if you look at the queueing and > network latency breakdowns. > > The saturation throughput is the injection rate at which the latency > shoots up. > Alternately, you can plot the total packets received per cycle as a > function of injection rate, and you will see that number saturating. > > Cheers, > Tushar > > On Jul 3, 2019, 11:08 AM -0400, CARLOS ANDRES PIEDRAHITA VELASQUEZ < > [email protected]>, wrote: > > Thank you Kushar for your kind response, now I get it. > > I have one more question though, in SwitchAllocator.cc in the method > send_allowed, for flits that are HEAD or HEADTAIL, why is not necessary > credit checking? I'm asking this because I'm trying to reach saturation > throughput in a Mesh 4x4 injecting flits in vnet 0 (one-flit vnet with 1 > flit buffer depth by default). But, flit latency keeps growing unbounded as > I increase the injection rate (as if buffer was infinite). > > Thank for your attention. > > On Mon, Jul 1, 2019 at 1:19 AM Krishna, Tushar <[email protected]> > wrote: > > Those values are used when initializing the credits in OutVCstate for the > data and control VCs. > The flitBuffer object has infinite size but the actual number of flits > that can sit in it are controlled by the credits. > > - Tushar > On Jun 27, 2019, 2:44 PM -0700, CARLOS ANDRES PIEDRAHITA VELASQUEZ < > [email protected]>, wrote: > > Greetings Everyone, > > I want to modify the buffer depth of virtual channels in Garnet from the > default values (buffers_per_ctrl_vc = 1 and buffers_per_data_vc = 4). > Analyzing GarnetNetwork.cc, I can see that these attributes are > instantiated in GarnetNetwork's constructor (lines 65 and 66), but never > used anywhere in the code. Additionally, In VirtualChannel.cc the > attribute m_input_buffer is instantiated as a flitBuffer object with > infinite size (line 40). > > So, does this mean that the buffers in the virtual channels are of > infinite size?, is there something that I don't understand yet? > > Thank you for your kind attention. > > -- > Carlos A. Piedrahita-Velásquez > Universidad de Antioquia > > > "La información aquí contenida es para uso exclusivo de la persona o > entidad de destino. Está estrictamente prohibida su utilización, copia, > descarga, distribución, modificación y/o reproducción total o parcial, sin > el permiso expreso de Universidad de Antioquia, pues su contenido puede ser > de carácter confidencial y/o contener material privilegiado. Si usted > recibió esta información por error, por favor contacte en forma inmediata a > quien la envió y borre este material de su computador. Universidad de > Antioquia no es responsable por la información contenida en esta > comunicación, el directo responsable es quien la firma o el autor de la > misma." > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > -- > Carlos A. Piedrahita-Velásquez > Universidad de Antioquia > Medellín - Colombia > > > "La información aquí contenida es para uso exclusivo de la persona o > entidad de destino. Está estrictamente prohibida su utilización, copia, > descarga, distribución, modificación y/o reproducción total o parcial, sin > el permiso expreso de Universidad de Antioquia, pues su contenido puede ser > de carácter confidencial y/o contener material privilegiado. Si usted > recibió esta información por error, por favor contacte en forma inmediata a > quien la envió y borre este material de su computador. Universidad de > Antioquia no es responsable por la información contenida en esta > comunicación, el directo responsable es quien la firma o el autor de la > misma." > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Carlos A. Piedrahita-Velásquez Universidad de Antioquia Medellín - Colombia -- "La información aquí contenida es para uso exclusivo de la persona o entidad de destino. Está estrictamente prohibida su utilización, copia, descarga, distribución, modificación y/o reproducción total o parcial, sin el permiso expreso de Universidad de Antioquia, pues su contenido puede ser de carácter confidencial y/o contener material privilegiado. Si usted recibió esta información por error, por favor contacte en forma inmediata a quien la envió y borre este material de su computador. Universidad de Antioquia no es responsable por la información contenida en esta comunicación, el directo responsable es quien la firma o el autor de la misma."
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
