gem5-users@gem5.org

The gem5 Users mailing list

View all threads

dest_queueing_delay in the function incrementStats in NetworkInterface.cc

CW
C.-Y. Wu
Fri, Sep 29, 2023 5:11 PM

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

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