Hi,What does that fs effect mean?
On 10-Mar-2014 6:25 PM, "biswabandan panda" <[email protected]> wrote:

> if i am not wrong, this is FS effect.
>
>
> On Mon, Mar 10, 2014 at 6:20 PM, Praxal Shah <[email protected]> wrote:
>
>> Hi Andreas,
>> Thank you for the reply.
>> I understand that timing may change as I am changing bank configuration.
>> But my question is about *Number of memory Access to the main memory and
>> number of instructions simulated is changing for same program running on
>> different bank configuration. *
>> Sir, I am running same benchmark and not changing cache parameters. with
>> change in bank counts, Number of memory access how can change.
>> And number of Instructions simulated by CPU are also changing. Which are
>> there in stats file.Following are the numbers.
>>
>> *Bank Configuration                      |             Memory Access
>>        |           Number of instructions simulated*
>>
>> 4 Banks:
>> 4207595                                              3752886887
>>
>> 8Banks :
>> 4202333                                              3753032418
>>
>> 8Banks 2 Ranks:
>> 4200230                                               3752892951
>>
>> 16 Banks:
>> 4201427                                              3752889830
>> If I am running same program, then
>> *Number of instructions simulated should not change at least. *I want to
>> understand why there is minute difference between these number in place of
>> being the same number.
>> Thank you
>>
>>  On Mon, Mar 10, 2014 at 5:19 PM, Andreas Hansson <
>> [email protected]> wrote:
>>
>>>  Hi Praxal,
>>>
>>>  I am not using the ruby_fs.py script myself, so I could be wrong on
>>> this point, but I suspect it is using the O3 CPU by default?
>>>
>>>  If it is, I'm not surprised the behaviour changes slightly when you
>>> alter the memory system. The dynamic program flow is influenced by the
>>> timing of the load/store requests, and may change. Similarly, even if
>>> you're using the simple timing CPU, as you are running full system, the OS
>>> behaviour may very well change as you perturb the memory system timings.
>>>
>>>  In short, there are plenty reasons why things change, and if would be
>>> rather astonishing if you saw the same number of requests in all cases.
>>>
>>>  I hope that makes things a bit more clear.
>>>
>>>  Andreas
>>>
>>>   From: Praxal Shah <[email protected]>
>>> Reply-To: gem5 users mailing list <[email protected]>
>>> Date: Monday, 10 March 2014 06:24
>>> To: "[email protected]" <[email protected]>
>>> Subject: [gem5-users] Why system.ruby.dir_cntrl0.memBuffer.memReq is
>>> different for same benchmark but different Bank configurations?
>>>
>>>    Hi,
>>>
>>> I am running* same benchmark with different bank configuration for main
>>> memory* (Mem-size 1GB) as follows: 4 Banks, 8Banks, 8 Banks 2
>>> Ranks/DIMM, and 16 Bank 1 Rank/DIMM.
>>>
>>> I am not changing cache hierarchy. Cache parameters are
>>>
>>> --l1i_size=32kB --l1d_size=32kB  --l2cache --num-l2cache=1
>>> --l2_size=512kB
>>>
>>> (./build/X86/gem5.opt configs/example/ruby_fs.py
>>> --disk-image=disks/x86root-parsec.img
>>> --kernel=/binaries/x86_64-vmlinux-2.6.28.4-smp --script=/mem_access.rcS
>>> --cpu-clock=2GHz --l1i_size=32kB --l1d_size=32kB  --l2cache --num-l2cache=1
>>> --l2_size=512kB --mem-size=1GB -n 1
>>> )
>>>
>>> *Ideally,I should get request to main memory same for all the
>>> configureations. But I am getting following values for
>>> system.ruby.dir_cntrl0.memBuffer.memReq.*
>>>
>>> 4 Banks: 4207595
>>>
>>> 8Banks:4202333
>>>
>>> 8Banks 2 Ranks:4200230
>>>
>>> 16 Banks:4201427
>>>
>>> *Is it because of some limitation of gem-5 or something else ?*
>>>
>>> Please give me hint .
>>>  I have attached stats file for each of the simulation.
>>>  in rcS file. I am dumping stats ad reseting it before benchmark starts.
>>> So look at the other section of the stats.
>>>  --
>>> Praxal S Shah
>>> 9650493254
>>>
>>> -- 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.
>>>
>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>>> Registered in England & Wales, Company No: 2557590
>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
>>> 9NJ, Registered in England & Wales, Company No: 2548782
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> [email protected]
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>
>>
>>
>> --
>> Praxal S Shah
>> 9650493254
>>
>> _______________________________________________
>> gem5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
>
>
> --
>
>
> *thanks&regards *
> *BISWABANDAN*
> http://www.cse.iitm.ac.in/~biswa/
>
> "We might fall down, but we will never lay down. We might not be the best,
> but we will beat the best! We might not be at the top, but we will rise."
>
>
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to