Hello everyone, I ran some simulations with Garnet and noticed that the dest_queueing_delay is always 0. (Only the queueing_delay (queueing_latency) is printed in stats.txt; queueing_delay is the sum of src_queueing_delay and dest_queueing_delay.)
After checking the code and debug traces, I think I have figured out the reason. [NetworkInterface::wakeup(): Check the incoming flit link] 1. All message buffers declared in the sm files (of the Garnet_standalone protocol) have unlimited sizes. No flits would be placed in the stall queue. 2. If the stall queue is always empty, messageEnqueuedThisCycle is always False. Therefore, for every flit (TAIL_ or HEAD_TAIL_), the function incrementStats is always called at the same cycle when the flit is dequeued. When dest_queueing_delay is calculated, curTick() equals t_flit->get_dequeue_time(), so dest_queueing_delay is always 0. Limiting the queue sizes in directories will not change the result because all enqueued RequestMsg will be dequeued (and discarded) in the next cycle as described in Garnet_standalone-dir.sm. Besides, at every cycle, only one flit will be chosen by the SwitchAllocator and sent to the corresponding NetworkInterface. Even if the queues have only one slot, they will be emptied in time. It would be nice if someone can join the discussion and confirm my understanding. Thanks for reading. Chia
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
