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
>
> --
> Joel Hestness
> PhD Student, Computer Architecture
> Dept. of Computer Science, University of Wisconsin - Madison
> <http://m5sim.org/mailman/listinfo/gem5-dev>
> http://www.cs.utexas.edu/~hestness
>
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
