Xenomai includes a "dohell" script that can generate disk and network load. You can always just "dd" to a file for a while.
If you're running a Debian/Ubuntu based system, I've found that running "aptitude upgrade" if you have a few dated packages can be a major stress to the system. That gets you both network and disk load, and not so long ago had a decent chance of wedging the eMMC kernel driver (even without the Xenomai patches that 'tickled' the eMMC driver bug and made it more likely to happen). Opening GUI programs and moving windows around is another good stress. On 2/26/2014 9:48 AM, quikcj...@gmail.com wrote: > The stress tool generates cpu load only. But it is a good idea to consider > other load scenarios, too. The current test was done using ssh so there was > at least some network activity. Do you know of a good test tool which > allows to generate disk and network load? > > > Am Mittwoch, 26. Februar 2014 15:58:55 UTC+1 schrieb Charles Steinkuehler: >> >> Those are pretty good numbers. Did you have heavy network and disk >> (uSD/eMMC) load going as well? IIRC, the uSD/eMMC driver was >> responsible for the worst of the latency spikes I saw, but that's been >> some time ago and based on the OMAP kernel list traffic, it appears >> there have been lots of improvements to that code. >> >> On 2/26/2014 7:53 AM, quik...@gmail.com <javascript:> wrote: >>> >>> >>> I have recently tested kernel 3.8.13-rt9 ( >>> https://github.com/beagleboard/kernel/tree/3.8-rt) using >>> git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I >> am >>> using Ubuntu 12.04.4. The load was created using stress –cpu 1 which >>> generates a cpu load of about 100%. I then used cyclictest: >>> >>> >>> root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l1000000 -m -n >> -t1 >>> -p99 -i400 -q >>> >>> # /dev/cpu_dma_latency set to 0us >>> >>> T: 0 ( 770) P:99 I:400 C:1000000 Min: 14 Act: 19 Avg: 18 Max: 132 >>> >>> >>> uname -a reports: >>> >>> root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a >>> >>> Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 >>> 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux >>> >>> >>> I am absolutely surprised that the result is looking that good. >>> >>> >>> >>> Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: >>>> >>>> I am trying to figure out how to create a kernel for the BBB that >> supports >>>> PREEMPT_RT. It's kind of strange that the BBB's default kernel does not >>>> even have PREEMPT activated. Such a board doesn't fit to many embedded >>>> applications where we need at least some kind of determinism. It is >> even >>>> worse, that nobody seems to care about this problem. Contrary to that, >> the >>>> Raspberry PI's standard kernel has PREEMPT activacted from the very >>>> beginning. >>>> >>>> I have tested Robert Nelsons kernel 3.8.13-r9 ( >>>> https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have >>>> PREEMPT_RT activated by default. When doing so, it does not boot. But >>>> activating PREEMPT does work. However, development of this branch has >>>> stopped several months ago. The official source for RT Linux (3.8.13) >> has >>>> evolved since then. Meanwhile there's an rt17 patch set ( >>>> https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody >>>> give this a try? Does it work with the BBB? >>>> >>>> >>>> >>> >> >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net <javascript:> >> > -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
