csu3_am335x/EVSE/GPL/mtd-utils-2.1.2/tests/jittertest/README

$Id: README,v 1.2 2001/08/10 19:23:11 vipin Exp $

This is the README file for the JitterTest (and friends)
program.

This program is used to measure what the jitter of a
real time task would be under "standard" Linux.

More particularly, what is the effect of running
a real time task under Linux with background
JFFS file system activity.

The jitter is measured in milli seconds (ms) from
the expected time of arrival of a signal from a
periodic timer (set by the task) to when the
task actually gets the signal.

This jitter is then stored in a file specified
(or the default output file "jitter.dat").

The data  may also be sent out to the console by
writing to /dev/console (See help options. This is
highly desirable specially if you have redirected
your console to the serial port and are storing it
as a minicom log on another computer for later analysis
using some tools provided here).

This is particularly useful if you have a serial
console and are outputting "interesting" info
from inside some kernel task or driver.
(or something as simple as a "df" program running
periodically and redirecting o/p to the console).

One "interesting" thing that I have measured
is the effect of FLASH chip erases on the jitter
of a real time task.

One can do that by putting a printk at the
beginning of the flash erase routine in the MTD
flash chip driver.

Now you will get jitter data interspersed with
flash sector erase events. Other printk's can also
be placed at suspected jitter causing locations in
the system.



EXECUTING THE PROGRAM "JitterTest"

You may specify a file to be read by the
program every time it wakes up (every cycle).
This file is created and filled with some junk
data. The purpose of this is to test the jitter
of the program if it were reading from- say
a JFFS (Journaling Flash File System) file system.

By specifying the complete paths of the read and write
(o/p) files you can test the jitter a POSIX type
real time task will experience under Linux, under
various conditions.

These can be as follows:

1. O/P file on ram file system, no i/p file.

 In this case you would presumably generate other
"typical" background activity for your system and
examine the worst case jitter experienced by
a task that is neither reading nor writing to
a file system.

Other cases could be:

2. O/P to ram fs, I/P from JFFS (type) fs:

 This is specially useful to test the proper
operation of erase suspend type of operation
in JFFS file systems (with an MTD layer that
supports it).

  In this test you would generate some background
write/erase type activity that would generate
chip erases. Since this program is reading from
the same file system, you contrast the latencies
with those obtained with writes going to the same
fs.

3. Both read and writes to (or just write to) JFFS
file system:

  Here you would test for latencies experienced by
a program if it were writing (and optionally also
reading) from a JFFS fs.




Grabing a kernel profile:

This program can also conditionally grab a kernel profile.
Specify --grab_kprofile on the cmd line as well as
a "threshold" parameter (see help options by -?).

Any jitter greater than this "threshold" will cause the
program to read the /proc/profile file and dump it in
a local file with increasing file numbers. It will also
output the filename at that time to the console file specified.
This will allow you to corelate later in time the various profiles
with data in your console file and what was going on at that time.

These profile files may then be later examined by running them through
ksymoops.

Make sure you specify "profile=2" on the kernel command line
when you boot the kernel if you want to use this functionality.



Signalling the JFFS[2] GC task:

You can also force this program to send a SIGSTOP/SIGCONT to the
JFFS (or JFFS2) gc task by specifing --siggc <pid> on the cmd line.

This will let you investigate the effect of forcing the gc task to
wake up and do its thing when you are not writing to the fs and to
force it to sleep when you want to write to the fs.

These are just various tools to investigate the possibility of
achieving minimal read/write latency when using JFFS[2].

You need to manually do a "ps aux" and look up the PID of the gc
thread and provide it to the program.




EXECUTING THE PROGRAM "plotJittervsFill"

This program is a post processing tool that will extract the jitter
times as printed by the JitterTest program in its console log file
as well as the data printed by the "df" command.

This "df" data happens to be in the console log because you will
run the shell file fillJffs2.sh on a console when you are doing
your jitter test.

This shell script copies a specified file to another specified file
every programmable seconds. It also does a "df" and redirects output
to /dev/console where it is mixed with the output from JitterTest.

All this console data is stored on another computer, as all this data
is being outputted to the serial port as you have redirected the console
to the serial port (that is the only guaranteed way to not loose any
console log or printk data).

You can then run this saved console log through this program and it
will output a very nice text file with the %fill in one col and
corrosponding jitter values in the second. gnuplot then does a
beautifull plot of this resulting file showing you graphically the
jitters encountered at different fill % of your JFFS[2] fs.



OTHER COMMENTS:

Use the "-w BYTES" cmd line parameter to simulate your test case.
Not everyone has the same requirements. Someone may want to measure
the jitter of JFFS2 with 500 bytes being written every 500ms. Others
may want to measure the system performance writing 2048 bytes every
5 seconds.

RUNNING MULTIPLE INSTANCES:

Things get real interesting when you run multiple instances of this
program *at the same time*.

You could have one version running as a real time task (by specifing
the priority with the -p cmd line parameter), not interacting with
any fs or at the very least not reading and writing to JFFS[2].

At the same time you could have another version running as a regular
task (by not specifing any priority) but reading and writing to JFFS[2].

This way you can easily measure the blocking performance of the real time
task while another non-real time task interacts with JFFS[2] in the back ground.

You get the idea.


WATCH OUT!

Be particularly careful of running this program as a real time task AND
writing to JFFS[2]. Any blocks will cause your whole system to block till
any garbage collect initiated by writes by this task complete. I have measured
these blocks to be of the order of 40-50 seconds on a reasonably powerful
32 bit embedded system.