Hey Ryan, Sorry for the slow reply. Yes, it looks like delayedTicks may be double counting in some cases. I wonder if a little microbenchmark might be able to confirm more clearly? Assuming it is being double counted, we'd welcome a fix!
@Bharadwaj, Srikant <[email protected]> might be able to help as well. Srikant, did you see anything like this with Garnet 3.0? Cheers, Jason On Fri, Sep 11, 2020 at 2:35 AM Gambord, Ryan via gem5-dev < [email protected]> wrote: > bump > > On Tue, Sep 1, 2020, 12:21 Gambord, Ryan <[email protected]> wrote: > >> I noticed that MessageBuffer calls UpdateDelayedTicks in both enqueue and >> dequeue methods. Since dequeue does not setLastEnqueueTime of the message >> to the time it was dequeued at, when enqueue calls UpdateDelayedTicks, >> doesn't it add the dequeue delay to the delayed ticks a second time? >> >> Below is a table of the timeline. X and Y are the starting values for >> LastEnqueueTime and DelayedTicks when the first message buffer receives the >> message. When the message is dequeued from MB1, DelayedTicks gets C-B added >> to it. When it is then enqueued in MB2, it gets D-B added, which double >> counts the C-B interval. >> >> curTime() FunctionCall m_LastEnqueueTime m_DelayedTicks >> >> >> X Y >> A enqueue() B = A + Delta Y + (A-X) >> B wakeup() " " >> C dequeue() " Y + (A-X) + (C-B) >> D enqueue() E = D + Delta >> Y + (A-X) + (C-B) + (D-B) = Y + (A-X) + (C-B) + (D-C) + (C-B) >> >> >> Ryan Gambord >> <[email protected]> >> >> _______________________________________________ > gem5-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
