One possible source is if your benchmark interacts with the host through a system call that returns a non-deterministic result. You could try running with the SyscallVerbose debug flag to see what syscalls it is making.
Steve On Sat, Aug 15, 2015 at 6:53 PM Prathap Kolakkampadath <[email protected]> wrote: > > I am observing this behaviour with a synthetic benchmark(Nonlinear > Predictive Control). I am not sure if this benchmark is adding any kind of > randomness. > I need to look in to this. > > I tested with eembc benchmarks, where i don't see any variations with the > repeated runs. > So as andreas mentioned this must be introduced by this specific benchmark. > > Thanks Andreas and Steve. > > On Thu, Aug 13, 2015 at 1:22 PM, Steve Reinhardt <[email protected]> wrote: > >> Even with x86 you should be seeing deterministic results. If you are >> regularly seeing inconsistencies, you can try running two copies with debug >> tracing (I suggest Exec,ExecMacro,Cache as a starting set of flags) and >> comparing their output with util/tracdiff to see where they diverge. >> >> Steve >> >> On Thu, Aug 13, 2015 at 9:44 AM Andreas Hansson <[email protected]> >> wrote: >> >>> Hi Prathap, >>> >>> That sounds very odd and should not happen unless the workload itself is >>> somehow random. What is it you are running? Are you sure you’re running >>> exactly the same thing? >>> >>> If it does indeed vary then it would be good if you can track down why >>> by running two simulations in lock-step and determining where they diverge. >>> >>> We regularly run the ARM regressions with UBSan to ensure there is no >>> undefined behaviour in the simulator. I know that for X86 there are quite a >>> few warnings from UBSan, so that could be a reason if you’re using x86. >>> >>> Andreas >>> >>> From: gem5-users <[email protected]> on behalf of Prathap >>> Kolakkampadath <[email protected]> >>> Reply-To: gem5 users mailing list <[email protected]> >>> Date: Thursday, 13 August 2015 09:11 >>> To: gem5 users mailing list <[email protected]> >>> Subject: [gem5-users] Sources of In-determinism in Full System >>> Simulators >>> >>> Hello User, >>> >>> I am running a benchmark in gem5 full system mode. Checkpoint is created >>> in atomic mode and then switches to detailed mode before starting the >>> benchmark. On repeated runs of the benchmark from same checkpoint, the >>> number of memory requests arriving at DRAM banks differs; up-to 5% >>> variation. Can someone point out, what could be the sources of >>> in-determinism? >>> >>> >>> Thanks, >>> Prathap >>> >>> -- 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 >> >> >> _______________________________________________ >> 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
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
