diff options
Diffstat (limited to 'jittertest/README')
| -rw-r--r-- | jittertest/README | 197 |
1 files changed, 0 insertions, 197 deletions
diff --git a/jittertest/README b/jittertest/README deleted file mode 100644 index f411a2c..0000000 --- a/jittertest/README +++ /dev/null @@ -1,197 +0,0 @@ -$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. |