On Thu, Feb 2, 2017 at 6:48 PM, Ran Shalit <ranshalit@xxxxxxxxx> wrote: > On Thu, Feb 2, 2017 at 4:53 PM, Julia Cartwright <julia@xxxxxx> wrote: >> On Thu, Feb 02, 2017 at 07:53:55AM +0200, Ran Shalit wrote: >>> Hello, >> >> Hello Ran- >> >>> I have followed instruction for using cycletest in: >>> https://rt.wiki.kernel.org/index.php/Cyclictest >>> >>> It described command lines for different scenarios. >>> usually one with load and the next without load. >>> Yet, I see no difference between the load 100% and no-load commands. >>> >>> How can you simulate load with cycletest ? >> >> cyclictest itself doesn't do any loading, it's common to run it with >> some other processes in the background which generate a simulated load. >> >> Keep in mind that the using a utility like the ones I've listed below is >> only _simulating_ what a load _might_ be like in a real application. >> The best thing to do is to actually test your application. >> >> - hackbench - scheduling load (nice because it's part of rt-tests) >> - stress - load-generating swiss-army knife >> - xfstests - disk / filesystem load >> - 'make -j' in a kernel source tree >> - iperf - network load >> - glxgears - gfx load >> Hi, If I may please ask one more on this subject: I have made several tests today with cyclictest, and I noticed that even if I just click the shell or open another shell it results immediately in a larger max value, especially in non-rt linux. So, it seems that even if I won't simulate 100% load I will get very easily to the max value if I do some actions in the environment, Right ? But the more important question is: Is it important if the cpu is 100% or 50%, (or even less) , i.e. should I expect to get the same (probably) max value in both cases ? Best Regards, Ran >> (those are the ones that come to mind, there are others I'm forgetting) >> >> Julia > > Hi Julia , Joakim , Kannan, > > Thank you very much for answering my question ! > > Regards, > Ran -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
