Re: [Gems-users] Change in cpu frequency

[Dan Gibson <degibson@xxxxxxxx>]

I would agree with your evaluation that the 75 MHz checkpoints are OK.

As for the deadlock, all I can say is that Ruby is a very complicated 
piece of code, and minor changes can have major impacts... I know that 
unmodified Ruby runs Apache/Jbb/OLTP/Zeus for a LONG time without any 
deadlock concerns here at Wisconsin. Which protocol are you using, by 
the way? Protocol bugs have been discovered like this in the past...
Regards,
Dan

Lide Duan wrote:
> Thank you both for the replies !
>
> So usually we don't care much about the actual cpu frequency in Simics 
> as long as the related parameters in GEMS are set to reasonable values 
> which are measured in cycles, right? If so, I would like to use the 
> original checkpoints instead of the 5ghz ones.
> About the dead lock problem, the jbb and barnes workloads ( I mean the 
> original checkpoints at 75mhz ) were running fine with my modified 
> ruby, but I did encounter a possible dead lock when running ocean 
> checkpoint. I don't know if it was due to my modification to ruby, but 
> I did nothing but added some counters to measure something, which 
> should not affect the behaviors of ruby. I will keep looking, and post 
> the problem if it comes again, but thank you anyway.
> Lide
>
> On 8/15/07, *Niket Agarwal (niketa@xxxxxxxxxxxxx 
> <mailto:niketa@xxxxxxxxxxxxx>)* <niketa@xxxxxxxxxxxxx 
> <mailto:niketa@xxxxxxxxxxxxx>> wrote:
>     What is the topology that you are using and what is the finite
>     buffer size you have ? I might help you out with the deadlock.
>
>     - Niket
>
>     > GEMS is pretty much divorced from what Simics thinks is "one
>     cycle". Simics generally uses an artificially low CPU speed to
>     effectively speed up I/O -- recall that Simics models a CPI 1.0
>     processor anyway when no timing models are installed. Ruby, on the
>     other hand, maintains its own notion of time, namely every
>     [SIMICS_RUBY_MULTIPLIER] simics cycles is equivalent to one Simics
>     cycle, modulo some transient behaviors. Thus, a 75MHz and a 5GHz
>     processor both observe the same *relative* memory system latencies
>     with Ruby, when measured in processor cycles.
>     > To put it another way, changing Simics's MHz doesn't affect Ruby.
>     >
>     >
>     > That said, let me address your other issues (long simulation
>     time and apparent deadlock). The long simulation time is
>     undoubtedly an artifact of the changing of the relative I/O speed.
>     In order to simulate a "disk access", Simics has to run about 100x
>     longer when simulating a 5 GHz processor than it does w/ 75 MHz.
>     Hence, we generally opt for a "slow" CPU speed to improve
>     simulator performance due to compulsory I/O behavior. Since all
>     latencies are relative, changing Simics's CPU speed only affects
>     I/O, not memory latency. As for the deadlock concern, I don't know
>     what might be causing that. Whereabouts in Ruby's code is the
>     error arising?
>     > Regards,
>     > Dan
>     >
>     > Lide Duan wrote:
>     >
>     >
>     >     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 magi
>     c 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
>     >    
>     ------------------------------------------------------------------------
>     >
>     >     _______________________________________________
>     >     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
>     <http://www.cs.wisc.edu/%7Egibson> [esc]:wq!
>     >
>     >
>
>     _______________________________________________
>     Gems-users mailing list
>     Gems-users@xxxxxxxxxxx <mailto: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/
>     <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!