Re: [Xenomai-core] Re: xeno-test updates [patch]
Jan Kiszka wrote: Jim Cromie wrote: Philippe Gerum wrote: Jim Cromie wrote: I hope thats everything for now, it needs a good shakedown, and I need a beer. Eh, I hope you had it by now, otherwise, you must be so damn thirsty... :o> :-) Ya gotta try this - simple, but highly addictive. A sport we can *all* play. http://www.wagenschenke.ch/site/homerun.htm Great thread, absolutely brilliant link! Just forwarded to our stag night crew for preparing the next weekend appropriately (we are going to rock Hamburg with the "victim"). :o) Jan I wanna party with you guys ! ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: xeno-test updates [patch]
Jim Cromie wrote: > Philippe Gerum wrote: >> Jim Cromie wrote: >>> I hope thats everything for now, >>> it needs a good shakedown, and I need a beer. >>> >> >> Eh, I hope you had it by now, otherwise, you must be so damn >> thirsty... :o> >> > :-) Ya gotta try this - simple, but highly addictive. A sport we can > *all* play. > > http://www.wagenschenke.ch/site/homerun.htm > Great thread, absolutely brilliant link! Just forwarded to our stag night crew for preparing the next weekend appropriately (we are going to rock Hamburg with the "victim"). :o) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: xeno-test updates [patch]
Philippe Gerum wrote: Jim Cromie wrote: cycletest now has decent options passed in. I havent given any thought to exposing options thru xeno-test's command line. Instead, Im thinking of adding statistics, ala latency. for that, Im also pondering a new -g 100 option to group the tests for stats-calcs, ie given: -g 100 -l 1000 -v it would compute statistics on 10 sets of 100 cycles, and report 10 lines. Again, this is notional, comments/feedback needed. This would be mainly useful for running different test scenarii - i.e. one per cycle? - I guess. But then, would not we have problems interpreting the results, since different testcases might lead to unrelated data sets? IOW, how would we use such data sets? Several observations led me to this idea. - in normal mode, the prog rewrites the same display line over and over it plays-back oddly when you more/cat the file. - with -v, it prints successive lines, but less info per line (no avg) which makes sense, since the avg is at the bottom. - 1000 lines of output is a boat-load, each is individually uninteresting / almost same as others. with latency, each line/second of the output contains the average of *many* samples 10,000 samples of 100uS measures IIRC, and the inner min,max,avg tell us about the high-frequency jitter,etc in the processes. Then the multiple samples tell us something about the low-freq jitter. IOW, we get a glimpse into the ergodicity of the noise (I say that, pretending I _understand_ ergodicity) Whether it applies / makes sense here, Im not at all sure. I hope thats everything for now, it needs a good shakedown, and I need a beer. Eh, I hope you had it by now, otherwise, you must be so damn thirsty... :o> :-) Ya gotta try this - simple, but highly addictive. A sport we can *all* play. http://www.wagenschenke.ch/site/homerun.htm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: xeno-test updates [patch]
Jim Cromie wrote: Jim Cromie wrote: Ive started adding to xeno-test, as outlined previously (plus some) , except where noted - now run cyclictest and switch, in addition to latency -t 0,1,2 cycletest now has decent options passed in. I havent given any thought to exposing options thru xeno-test's command line. Instead, Im thinking of adding statistics, ala latency. for that, Im also pondering a new -g 100 option to group the tests for stats-calcs, ie given: -g 100 -l 1000 -v it would compute statistics on 10 sets of 100 cycles, and report 10 lines. Again, this is notional, comments/feedback needed. This would be mainly useful for running different test scenarii - i.e. one per cycle? - I guess. But then, would not we have problems interpreting the results, since different testcases might lead to unrelated data sets? IOW, how would we use such data sets? - changed the prewired -m email-addy to [EMAIL PROTECTED] email options now work w/o actually writing a file. Also changed default location of file writes to /tmp, they no longer get written to $PWD by default Nice for embedded setups. added a -U , completely untested, but mostly lifted from LiveCD This looks necessary, since my hobby-box doesnt have a working mail setup my laptop (and presumably yours) doesnt have a FQDN, which pretty well precludes sending mail to anywhere useful. (Id bet we could span the unwashed winbloze masses, but wheres the sport in that ? ;-) - now grep more config-items out of config (for non-verbose mode) latency-killers, PREEMPT, others ? added items per RPMs email. Im considering stripping the warning issued when CPU_FREQ ia xonfig'd warning: CONFIG_CPU_FREQ=y may be problematic. I have it in cuz nothing actually changes (can change) it, so its harmless. (I think) Its easier than making the list complete, and the .config dump covers the reporting. Sounds reasonable; in any case, .config would be analyzed in case of problem. Dont apply yet, not tested recently. Its reasonbly tested; we can shake out some more with some distributed testing (hint - try it !) Merged, now. Thanks. Heres some tests I ran, files got written.. ./xeno-test -T 30 -l30 -m ./xeno-test -T 30 -l30 ./xeno-test -T 30 -l30 -L ./xeno-test -T 30 -l30 -N foo ./xeno-test -T 30 -l30 -LN bar ./xeno-test -T 30 -l30 -LN buzz -m ./xeno-test -T 5 -l30 -L -m ./xeno-test -T 5 -l30 -N /tmp/box- -m ./xeno-test -T 5 -l30 -N ~/trucklab/ -w2 -W 'dd if=/dev/hda1 of=/dev/null' Qs - should I run boxstatus just after latency tests or b4 and after (as currently) ? - /proc/xenomai/* contents are dynamic (ie run by boxstatus) ? - any bits of boxinfo and boxstatus that should be shuffled around ? - check NPTL availability (kinda overkill, since its absence when needed is already detected) - anything else come to mind ? these are still open, but not crtical. I think we will discover new stuff to add incrementally, after getting some practical experience on the automated data collection issue. I hope thats everything for now, it needs a good shakedown, and I need a beer. Eh, I hope you had it by now, otherwise, you must be so damn thirsty... :o> -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: xeno-test updates [patch]
Jim Cromie wrote:
Ive started adding to xeno-test, as outlined previously (plus some)
, except where noted
- now run cyclictest and switch, in addition to latency -t 0,1,2
cycletest now has decent options passed in.
I havent given any thought to exposing options thru xeno-test's command
line.
Instead, Im thinking of adding statistics, ala latency.
for that, Im also pondering a new -g 100 option to group the tests for
stats-calcs,
ie given: -g 100 -l 1000 -v
it would compute statistics on 10 sets of 100 cycles, and report 10 lines.
Again, this is notional, comments/feedback needed.
- changed the prewired -m email-addy to [EMAIL PROTECTED]
email options now work w/o actually writing a file.
Also changed default location of file writes to /tmp,
they no longer get written to $PWD by default
added a -U , completely untested, but mostly lifted from LiveCD
This looks necessary, since
my hobby-box doesnt have a working mail setup
my laptop (and presumably yours) doesnt have a FQDN,
which pretty well precludes sending mail to anywhere useful.
(Id bet we could span the unwashed winbloze masses, but wheres
the sport in that ? ;-)
- now grep more config-items out of config (for non-verbose mode)
latency-killers, PREEMPT, others ?
added items per RPMs email.
Im considering stripping the warning issued when CPU_FREQ ia xonfig'd
warning: CONFIG_CPU_FREQ=y may be problematic.
I have it in cuz nothing actually changes (can change) it, so its
harmless. (I think)
Its easier than making the list complete,
and the .config dump covers the reporting.
Dont apply yet, not tested recently.
Its reasonbly tested; we can shake out some more with some distributed
testing
(hint - try it !)
Heres some tests I ran, files got written..
./xeno-test -T 30 -l30 -m
./xeno-test -T 30 -l30
./xeno-test -T 30 -l30 -L
./xeno-test -T 30 -l30 -N foo
./xeno-test -T 30 -l30 -LN bar
./xeno-test -T 30 -l30 -LN buzz -m
./xeno-test -T 5 -l30 -L -m
./xeno-test -T 5 -l30 -N /tmp/box- -m
./xeno-test -T 5 -l30 -N ~/trucklab/ -w2 -W 'dd if=/dev/hda1 of=/dev/null'
Qs
- should I run boxstatus just after latency tests or b4 and after (as
currently) ?
- /proc/xenomai/* contents are dynamic (ie run by boxstatus) ?
- any bits of boxinfo and boxstatus that should be shuffled around ?
- check NPTL availability (kinda overkill, since its absence when
needed is already detected)
- anything else come to mind ?
these are still open, but not crtical.
I hope thats everything for now,
it needs a good shakedown, and I need a beer.
Index: scripts/prepare-kernel.sh
===
--- scripts/prepare-kernel.sh (revision 974)
+++ scripts/prepare-kernel.sh (working copy)
@@ -48,6 +48,7 @@
patch_append() {
file="$1"
if test "x$output_patch" = "x"; then
+ chmod +w "$linux_tree/$file"
cat >> "$linux_tree/$file"
else
if test `check_filter $file` = "ok"; then
Index: scripts/xeno-test.in
===
--- scripts/xeno-test.in(revision 974)
+++ scripts/xeno-test.in(working copy)
@@ -12,15 +12,18 @@
-W
