Hey Nilay, The only regressions that changed were those that use the Ruby memory controller, and the only real changes were in the stats and config files. Was there supposed to be something else here?
Thanks, Joel On Sun, Sep 9, 2012 at 2:08 PM, Nilay Vaish <[email protected]> wrote: > Joel, you did not update all the regression tests. > > -- > Nilay > > > On Fri, 7 Sep 2012, Joel Hestness wrote: > > Hey Andreas, >> I verified all the changes when I pushed these. The messy thing about >> the Ruby regressions is that they use a tick length of 1ns instead of the >> 1ps which is default in the rest of the mainline. Because of this, the >> 400MHz default for the memory controller is converted to a 3 tick clock >> (2.5ns = 2.5 ticks, rounded up), so everything there looks correct. >> >> Regarding the stats differences, they are only present in the memory >> bandwidth and the simulated runtime. These regressions were previously >> using a 10 tick memory controller cycle, which equated to 10ns = 100MHz >> (and a "crazy" 100GHz by default in the mainline with tick = 1ps). By >> fixing the way the memory controller clock works - specifying the >> frequency >> and deriving the clock/cycle time from that - it fixes the crazy default >> cycle time in the mainline. I set the default memory frequency to 400MHz >> both as a somewhat more reasonable frequency than the really old default >> of >> 200MHz, and as a way to verify that the stats changed in a reasonable way. >> >> The memory bandwidth roughly doubles from the old regressions, which >> makes sense: Previously, the memory frequency was 100MHz in these >> regressions, and with the rounding to 3 ticks per cycle now, the new >> frequency for the Ruby regressions is 333MHz. These regressions hammer >> the >> memory system to test the coherence protocols, so double memory bandwidth >> is reasonable (and I've very thoroughly tested changing the frequency in >> my >> sandbox repo and every thing checks out). The simulated runtime gets cut >> by approximately half because all of these regressions are memory >> bandwidth >> limited. >> >> A bigger issue to note from this whole memory controller clocking issue >> is that using a tick length of 1ns for these regressions is probably a bad >> idea. In the case of this memory controller bug, the tick length masked >> the clocking issue by setting the memory controller frequency at >> effectively 100MHz in the regressions, while, if you change the tick >> length, the memory controller frequency would change inversely >> proportionally. In the future, I'd advocate for all regressions to use >> the >> default 1ps tick just so these sorts of bugs manifest themselves more >> clearly, especially as all of the clocking changes are getting pushed >> currently. >> >> Joel >> >> >> >> On Fri, Sep 7, 2012 at 10:27 AM, Andreas Hansson <[email protected] >> >**wrote: >> >> Hi everyone, >>> >>> It seems I was too optimistic. There are also quite some substantial >>> stats >>> differences for the regressions in question. >>> >>> Joel, could you perhaps give them another bump (and a manual inspection >>> to >>> ensure it all makes sense)? >>> >>> Andreas >>> >>> >>> -- IMPORTANT NOTICE: The contents of this email and any attachments are >>> confidential and may also be privileged. If you are not the intended >>> recipient, please notify the sender immediately and do not disclose the >>> contents to any other person, use it for any purpose, or store or copy >>> the >>> information in any medium. Thank you. >>> ______________________________**_________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >>> >>> -- >>> Joel Hestness >>> PhD Student, Computer Architecture >>> Dept. of Computer Science, University of Wisconsin - Madison >>> >>> <http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >>> > >>> http://www.cs.utexas.edu/~**hestness<http://www.cs.utexas.edu/~hestness> >>> >>> >>> ______________________________**_________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://www.cs.utexas.edu/~hestness _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
