The loops per jiffy is passed to the kernel (see FSConfig.py) so the kernel doesn't try to compute it (as it takes a long time). It probably should be based on a the CPU frequency gem5 is simulating, but it's just fixed at the moment. As long as you have a homogenous system it shouldn't be a problem.
Ali On Jun 8, 2013, at 7:42 AM, Fernando Endo <fernando.en...@gmail.com> wrote: > Hello, > > I didn't follow the whole discussion, but I have a point, regarding the > Timing model: > > 1) If you run with caches, usually what happens when running linux, your cpu > isn't limited by the slow main memory, so your bogomips may change with the > cpu frequency. > > 2) If you run without caches and with relative high clock speeds, your cpu > will be mainly limited by the slow main memory, so the latter will basically > define your apparent constant bogomips ~33. > > If you try to without caches and a very slow cpu freq, I'd say your bogomips > could be less than ~33. > > Hope it helps, > > Fernando > > -- > Fernando A. Endo, PhD student and researcher > > Université de Grenoble, UJF > France > > > > 2013/6/6 Guru Prasad <gurup...@buffalo.edu> > Please disregard the previous E-mail. > It has some wrong facts > > > Hi All, > > A small follow-up on this question. > > TimingSimpleCPU model seems to work more consistently with --caches enabled. > However, the Linux kernel is still unable to accurately compute loops per > jiffy for the timing model CPU..(it always computes 997 BogoMIPS) > > My program output also seems to suggest that regardless of the --clock > frequency specified, the output is always the same and it is close to the > values obtained from AtomicSimpleCPU model running at 1GHz. > > AtomicSimpleCPU > build/ARM/gem5.fast configs/example/fs.py -b cpufreq_test --kernel > /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image > /home/guru/gem5/gem5-dev/system/disks/android_jb_pa_final.img > --machine-type=VExpress_EMM --clock=1GHz --cpu-type=atomic --num-cpus=1 > > [ 1.769154] Time taken :0.0100000s > [ 1.769157] Number :14249 > > > TimingSimpleCPU (with --caches) > build/ARM/gem5.fast configs/example/fs.py -b cpufreq_test --kernel > /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image > /home/guru/gem5/gem5-dev/system/disks/android_jb_pa_final.img > --machine-type=VExpress_EMM --clock=1GHz --cpu-type=timing --caches > --num-cpus=1 > > [ 1.925451] Time taken :0.0100010s > [ 1.925457] Number :12300 > > > I have also noticed that without --caches, the kernel always computes 32.97 > BogoMIPS regardless of the --clock argument specified.. > > TimingSimpleCPU (without --caches) > build/ARM/gem5.fast configs/example/fs.py -b cpufreq_test --kernel > /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image > /home/guru/gem5/gem5-dev/system/disks/android_jb_pa_final.img > --machine-type=VExpress_EMM --clock=1GHz --cpu-type=timing --num-cpus=1 > > [ 5.286962] Time taken :0.0100310s > [ 5.287082] Number :454 > > > In both TimingSimpleCPU configurations, regardless of the --clock parameter > specified, the output does not vary much from the specified values. > > I'm still not sure as to why this is happening.. > > Any thoughts? > > > Regards > > > On Thu, Jun 6, 2013 at 11:01 AM, Guru Prasad <gurup...@buffalo.edu> wrote: > Hi All, > > A small follow-up on this question. > > @Tao Zhang was actually right. > Timing CPU works as 'expected' when I enable caches with it. > > Why I say 'expected' is because, the Linux kernel is still unable to > accurately compute loops per jiffy for the timing model CPU..(it always > computes 997 BogoMIPS) > However, the output seems to now correlate with changes in --clock values (I > don't know if its correct though..what I mean is - higher clock seems to > correspond to more operations executed). > > I have also noticed that without --caches, the kernel always computes 32.7 > BogoMIPS regardless of the --clock argument specified.. > I'm still not sure as to why this is happening.. > > Any thoughts? > > > Regards > Guru > > > > On Mon, Jun 3, 2013 at 10:31 AM, Guru Prasad <gurup...@buffalo.edu> wrote: > Hello All, > > I received clarification from > qa.gem5.org(http://qa.gem5.org/132/timing-cpu-model) on this issue. > "The TimingSimpleCPU is a 1 CPI CPU model that uses a timing back-end for > memory latencies, so it's not surprising that you'd see little change in a > cpu-bound benchmark when varying the clock. Try running a memory intensive > benchmark, such as mcf from SPEC, and you should see a difference. If you > need detailed timing information out of the CPU, use the O3 model." - Tony > > Regarding the other questions that I have not responded to, > > @Tao Zhang, > I just never enabled --caches as Gem5 did not complain about it (Gem5 does > complain about it when trying to use o3 model without caches). > I was a little doubtful about --cpu-type=detailed..I had questioned this > earlier as well..My CPU bound benchmark works as intended while using > arm_detailed with --caches. > > @Rehab Massoud, > The time does make sense, yes. But the last number computed should be > proportional to the CPU frequency..the higher the frequency, the more > computations per unit time. However, the timing model was not reflecting > this..hence my post. > > @Andrws Vieira, > The variable 'Number' is the last number that it tried to test (whether it > was prime or not). > > My primality test function is as follows, > > typedef unsigned long long ull; > static inline int is_prime(int number) { > > ull divisor = 3; > > if(number == 1ULL ) { > //1 is neither prime nor composite > return 0; > } > > if(number % 2 == 0) { > return 0; //even no. > } > > // Every prime number is of the form 6n (+|-) 1 > if(number % 6 != 1 || number % 6 != 5) { > return 1; > } > > while ( divisor <= (number / 2) ) { > if (number % divisor == 0) { > return 0; > } > divisor += 2; > } > return 1; > } > > Below is the pseudo code of my main function > main(argc, argv) { > ... > start_time = get_current_time() > > ull number = 1; > while(1) { > is_prime(number); > if( (get_current_time() - start_time) >= end_time //end_time part of > argv > break; > number++; > } > } > > Thank you for your insights into this issue.. > > Regards > Guru > > > > On Fri, May 31, 2013 at 6:27 AM, Andrws Vieira <andrwsvie...@gmail.com> wrote: > Hello Guru, > > What is the variable "Nunber" ? > > > []'s > > > 2013/5/31 Rehab Massoud <rehab.mass...@gmail.com> > Didn't you say that you're running a program that's given a timeout? The > timeout you specify is expected to be the time you got, so your results make > all the sense, isn't it? > > On May 31, 2013 8:24 AM, "Guru Prasad" <gurup...@buffalo.edu> wrote: > Hi Andrws, > This is the output i obtained running with the configuration mentioned. > > 01 GHz > Time taken :0.1000000s > Number :189055 > > > 04 GHz > Time taken :0.1000000s > Number :392151 > > > 10 GHz > Time taken :0.1000000s > Number :472726 > > It does seem to correlate with what I would expect to be the output with > change in frequency. > > I will need to test further (or read appropriate documentation) to ensure > that timing model is actually being used in the command line mentioned above. > > Thank you for your suggestions. > > Regards > Guru > > > > On Thu, May 30, 2013 at 2:55 PM, Guru Prasad <gurup...@buffalo.edu> wrote: > Hi Andrws, > > I'm running the simulations right now.. > Could I ask how this makes a difference? > > Also, (How) is this different from --cpu-type=arm_detailed? > > This will be my command line..do let me know if there is an issue with it > build/ARM/gem5.fast configs/example/fs.py --kernel > /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image > /home/guru/gem5/gem5-stable/system/disks/android_jb_pa_spec.img > --machine-type=VExpress_EMM --clock=1GHz --cpu-type=timing --num-cpus=1 > --caches --cpu-type=detailed > > > > Regards > Guru > > > > On Thu, May 30, 2013 at 2:36 PM, Andrws Vieira <andrwsvie...@gmail.com> wrote: > Hi Guru, > > Try to put in the end of command line: cpu-type=detailed > > Like this -> build/ARM/gem5.fast configs/example/fs.py --kernel > /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image > /home/guru/gem5/gem5-stable/system/disks/android_jb_pa_spec.img > --machine-type=VExpress_EMM --clock=4GHz --cpu-type=timing --num-cpus=1 > --cpu-type=detailed > > > []'s > > > 2013/5/30 Guru Prasad <gurup...@buffalo.edu> > Here are some results > > Atomic > 01 GHz > Time taken :0.1000006s > Number :142617 > > 04 GHz > Time taken :0.1000003s > Number :575327 > > 10 GHz > Time taken :0.1000003s > Number :1428815 > > > > Timing > 01 GHz > Time taken :0.1000310s > Number :4597 > > 04 GHz > Time taken :0.1000302s > Number :4657 > > 10 GHz > Time taken :0.1000297s > Number :4643 > > > Maybe this is how timing is supposed to work..I'm not sure.. > I just didn't understand it and wanted to ask other users > > Regards > Guru > > > > On Thu, May 30, 2013 at 2:09 PM, Guru Prasad <gurup...@buffalo.edu> wrote: > Hi Andreas, > > The output of my program is the same. > I'm running primality test program that is given a time bound. > > It returns the last number that it tested when it runs out of time. > > I would expect the last number computed to differ based on frequency > specified while running Gem5. > > This differs significantly when using both, Atomic model and O3.. > But regardless of the --clock parameter, timing model always gives me results > that are very close. > > > My command line parameters are > > build/ARM/gem5.fast configs/example/fs.py --kernel > /home/guru/gem5/kernel/linux-3.3-armdroid/vmlinux --disk-image > /home/guru/gem5/gem5-stable/system/disks/android_jb_pa_spec.img > --machine-type=VExpress_EMM --clock=4GHz --cpu-type=timing --num-cpus=1 > > I am working with a slightly outdated gem5 source..I believe my revision is > 9197 > > > > On Thu, May 30, 2013 at 1:57 PM, Andreas Hansson <andreas.hans...@arm.com> > wrote: > Hi Guru, > > Could you perhaps elaborate on "same results"? Are all stats exactly the > same, or is the output of the program the same? Also, what config script are > you running? > > Andreas > > From: Guru Prasad <gurup...@buffalo.edu> > Reply-To: gem5 users mailing list <gem5-users@gem5.org> > Date: Thursday, 30 May 2013 18:45 > To: "gem5-users@gem5.org" <gem5-users@gem5.org>, "gem5-...@gem5.org" > <gem5-...@gem5.org> > Subject: [gem5-users] Timing CPU model > > I was recently running some tests using the timing CPU model and noticed that > my cpu-bound workload was always producing the same results regardless of the > --clock parameter specified. > > I tested this with > --clock=0.1GHz (not sure if floating points work for parameters) > --clock=1GHz > --clock=4GHz > --clock=10GHz > > Could anyone explain to me why this is the case? Is there something implicit > in the timing model that I'm not quite grasping? > > -- 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-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > -- > Andrws Aires Vieira > Mestrando em Computação > Universidade Federal do Rio Grande do Sul - UFRGS > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > -- > Andrws Aires Vieira > Mestrando em Computação > Universidade Federal do Rio Grande do Sul - UFRGS > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
