[Gems-users] Change in cpu frequency


Date: Wed, 15 Aug 2007 16:20:45 -0500
From: "Lide Duan" <leaderduan@xxxxxxxxx>
Subject: [Gems-users] Change in cpu frequency
I have got some problems when I was trying to change the cpu frequency of my checkpoints.

Basically what I have done is: I added some counters to the ruby network code to record the delay cycles of each kind of messages, and dumped the results every some number of ruby cycles. I run the modified ruby on some checkpoints, e.g. SPECjbb2005, barnes, ocean, etc. The results seemed to be reasonable: some of the messages encountered some delays, and the delay cycles would increase if I reduce the bandwidth of the links or the finite buffer size. However, these checkpoints were created with cpu frequency at 75MHZ which was too low for the modern machines. I recreated some checkpoints with cpu frequency at 5GHZ, and supposed that the delay cycles would be much larger than those checkpoints at 75MHZ due to the much higher frequency.

However, strange things happened. For the jbb_5ghz checkpoint, I have run it for several days with ruby loaded, but it never reached the first magic instruction which was used to end the ruby warm up phase and start the real workload. For barnes_5ghz, I got the warm up checkpoint, but the simulation results from that were quite strange: the delay cycles of the messages are almost zero, and the simulation also stopped soon with a "Possible Deadlock detected" complain from GEMS. I am pretty confused because I didn't make more modification to ruby after changing the checkpoints, the only difference is the cpu frequency of the checkpoints.

So I am wondering is there any restriction on the cpu frequency that GEMS can support? I didn't find anything related in ruby configuration. How does GEMS deal with the cpu frequency? Also, what's the reasonable value of cpu frequency for current research? Is 75MHZ too low or 5GHZ too high?

Thanks,
Lide
[← Prev in Thread] Current Thread [Next in Thread→]