Re: [Gems-users] Change in cpu frequency - question

[Dan Gibson <degibson@xxxxxxxx>]

The ways of Simics are strange indeed. I have no idea why 75MHz would be blazing fast but 80MHz would be slow. You might try asking on the Simics forum about it. 

There is a higher-level point to consider. Bear in mind with the following comment that I have no idea what you're actually trying to simulate.

I would advise against simulating a workload that is actually performing I/O when you are taking measurements -- Simics' I/O timing isn't sufficiently realistic, and GEMS does nothing to improve I/O timing from what Simics provides. Instead, set up your workload so that its "I/O operations" are consistently hitting in memory -- either in the file cache or in a loopback device. In other words, make sure you have fully warmed your input sets from disk, and that you're not actually hitting any ethernet devices. Doing so creates a decent proxy for a server busy period, without spending CPU time just spinning in the idle loop (after all, its hard to convince reviewers that optimizing the idle loop is interesting).

Lastly, per my previous comment in the cited thread, its OK to run with 75 MHz checkpoints, so long as your workload isn't doing any I/O. The real benefit of having a higher clock frequency is that timer interrupts and spurious I/O interrupts should be a lot less frequent -- but if there aren't any other processes running besides your workload, the effect of the timer firing won't be problematic.

Regards,
Dan

On Sun, Feb 7, 2010 at 10:31 AM, Pradeep Ramachandran <pramach2@xxxxxxxx> wrote:

Thanks. I will look into the tick and tick compare registers to post interrupts later.

However, I am trying to understand why this is happening, and it seems strange that increasing the clock frequency to even 80MHz (from the default 75MHz) makes the simulation time exponentially shoot up to days of simulation for what used to take a few minutes. It looks like there are some optimizations that simics is doing at 75MHz. Any ideas why this may be happening?

Pradeep.

On Feb 6, 2010, at 7:00 PM, Philip Garcia wrote:

You can get around the 75MHz clock issue by stalling the timer interrupts  until you want them.  This can be done by manipulating the tick and tick compare register so that it goes off at specified times.

Phil

On Feb 6, 2010, at 5:14 PM, Pradeep Ramachandran wrote:

Hi,
I noticed from an old thread <https://lists.cs.wisc.edu/archive/gems-users/2007-August/msg00027.shtml> that users have experienced the problem of elevated simulation times when changing the default clock in the simics system from 75MHz to (more realistic) 2GHz. I am seeing a similar problem when I am trying to simulate a multithreaded server workload.

The message pointed to above says that it is probably ok to evaluate things with the 75MHz clock as the I/O simulation becomes a bottle-neck. However, at 75MHz, the timer interrupts forces a thread switch every 1m instructions or less. Won't that mess with the measurements (of performance and throughput)? Is there any simple method that people use to eliminate errors that may arise because of this?

Thanks in advance for the help,
Pradeep.

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users

Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users

Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.

-- 
http://www.cs.wisc.edu/~gibson [esc]:wq!