Hi Srikant, Thank you for looking into it. I noticed the miscalculation while working on something unrelated, and wasn't sure what those values were used for (I don't need them). If it's not being used, then my proposed change would be to remove it from the codebase as legacy bloat. Does anyone have a problem with that?
Ryan Gambord <gambo...@oregonstate.edu> On Mon, Sep 14, 2020 at 11:44 PM Srikant Bharadwaj via gem5-dev < gem5-dev@gem5.org> wrote: > [This email originated from outside of OSU. Use caution with links and > attachments.] > Hi Ryan, > You are right. If the message goes to the next message buffer, delay is > added again. > However, as far as I know we are not using the delayed ticks for > calculating anything anymore. The earlier use case was to calculate the > stall time within MessageBuffer, but we use the getTime to do that now. > Is there any specific use case you are trying to fix here? > > In any case, it would be great if you can post a fix. > > Thanks, > Srikant > > On Mon, Sep 14, 2020 at 10:48 AM Jason Lowe-Power via gem5-dev < > gem5-dev@gem5.org> wrote: > >> 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 <srikant.bharad...@amd.com> 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 < >> gem5-dev@gem5.org> wrote: >> >>> bump >>> >>> On Tue, Sep 1, 2020, 12:21 Gambord, Ryan <gambo...@oregonstate.edu> >>> 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 >>>> <gambo...@oregonstate.edu> >>>> >>>> _______________________________________________ >>> gem5-dev mailing list -- gem5-dev@gem5.org >>> To unsubscribe send an email to gem5-dev-le...@gem5.org >>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> >> _______________________________________________ >> gem5-dev mailing list -- gem5-dev@gem5.org >> To unsubscribe send an email to gem5-dev-le...@gem5.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > _______________________________________________ > gem5-dev mailing list -- gem5-dev@gem5.org > To unsubscribe send an email to gem5-dev-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
