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]<mailto:[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]<mailto:[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 [https://0c595a64-a-57bd039f-s-sites.googlegroups.com/a/udea.edu.co/repositorio-logos/home/firma/FIRMA_CAMPUS50.jpg] "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]<mailto:[email protected]> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Carlos A. Piedrahita-Velásquez Universidad de Antioquia Medellín - Colombia [https://0c595a64-a-57bd039f-s-sites.googlegroups.com/a/udea.edu.co/repositorio-logos/home/firma/FIRMA_CAMPUS50.jpg] "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
