Difference between revisions of "RTWG-discussion-points"
(→Interbench) |
|||
| Line 58: | Line 58: | ||
See http://members.optusnet.com.au/ckolivas/interbench/ | See http://members.optusnet.com.au/ckolivas/interbench/ | ||
| + | |||
| + | |||
| + | === celleb test === | ||
| + | Runs test with Linux on hypervisor. Hypervisor generates interrupt to Linux at periodic | ||
| + | intervals. The kernel measures the ISR start time, and can query the hypervisor for the | ||
| + | intended interrupt initiation time. | ||
| + | |||
| + | Results on page 7 are results from hdparm, normalized against a baseline configuration. | ||
| + | Note that page 7 shows results from a kernel with a bug (in the non-RT case). | ||
| + | |||
| + | set PPC64_TLB_BATCH_NR to 1 | ||
| + | why? | ||
| + | |||
| + | In english translation lpar = "logical partition". This refers to a single environment under | ||
| + | the hypervisor. The lpar interrupt was used because it was periodic. | ||
| + | |||
| + | hdparm used for load, not for measurement. The test provided 3 different measurements of performance. | ||
| + | |||
| + | Each run is a shown as a separate path on the graph. The paths are separated to be able | ||
| + | to distinguish the lines. (They have different 0-bases on the graph). | ||
| + | point on graph shows amount of latency for each interrupt. Interrupt is on horizontal axis. | ||
| + | |||
| + | page 14 shows interrupt latency, under load. | ||
| + | |||
| + | All results are shown normalized, to avoid disclosing actual numbers for the CELL processor | ||
| + | and hypervisor. | ||
| + | |||
| + | Stair-step results in the graph are from hdparm being run in a loop. Sometimes hdparm was | ||
| + | putting load on the system, and sometimes it was not (at regular intervals). | ||
| + | |||
| + | page 15 has previous results, with non-rt kernel with bug. | ||
| + | |||
| + | page 16 shows corrected results | ||
| + | |||
| + | page 18 - load is netperf | ||
| + | |||
| + | page 26 - send performance of nonRT kernel is used as baseline for normalization. | ||
| + | Measurement is of network performance (with several different configurations). | ||
| + | Result of good performance for non-RT kernel, but with interupt threading is | ||
| + | not expected. | ||
Revision as of 21:54, 3 September 2007
Contents
Review of test programs
lpptest
problems:
- requires 2 machines
- requires parallel port (not many embedded boards have this)
- uses TSC, which is i386-specific
benefits:
- built into the rt-preempt patch
- 2-machine system gives unbiased timing results
- instrumentation does not interfere with the timings
realfeel
benefits:
- is one-machine
- uses /dev/rtc, does not use timer interrupt
- this isolates the ISR handling from timer operations
- is a very simple test
problems:
- uses TSC, which is i386-specific
- doesn't have an instrumentation point in the kernel
- no measurement of int latency, only process start latency
- process start latency is "guessed" from expected interrupt time
- that is, it is not actually measured
- not all boards have a working /dev/rtc driver
igel test
This tests scheduling latency on receipt of a character on an SM501 uart. The UART driver gets a timestamp on ISR start, and can be asked for them from user-space after a run. The user-space driver measures the time from ISR start to task start. Test is specific to SH architecture. Uses SH hardware timer.
SH4 running at 240 MHZ, 64 MB memory.
See http://tree.celinuxforum.org/CelfPubWiki/UserLevelDeviceDriver (page is in Japanese)
See also: CELF Jamboree 14 presentation
- Yung Joon will ask Takao Ikoma to translate this page.
- Matsubara-san will update the driver and some of the text on the page.
- will attach latest driver source
- Tim will provide Ikoma-san e-mail
Test shows some important results:
- 2.6.16.4 has much better scheduling latency under load than 2.4.20
- test was with kernel preemption - withOUT RT-preempt patches loaded.
- signal delivery method of waking up tasks took a lot longer than unblocking an I/O operation
- signal delivery is a bad method to use for measuring RT performance
Interbench
Need to investigate, but looks like a test of scheduling latency.
See http://members.optusnet.com.au/ckolivas/interbench/
celleb test
Runs test with Linux on hypervisor. Hypervisor generates interrupt to Linux at periodic intervals. The kernel measures the ISR start time, and can query the hypervisor for the intended interrupt initiation time.
Results on page 7 are results from hdparm, normalized against a baseline configuration. Note that page 7 shows results from a kernel with a bug (in the non-RT case).
set PPC64_TLB_BATCH_NR to 1 why?
In english translation lpar = "logical partition". This refers to a single environment under the hypervisor. The lpar interrupt was used because it was periodic.
hdparm used for load, not for measurement. The test provided 3 different measurements of performance.
Each run is a shown as a separate path on the graph. The paths are separated to be able to distinguish the lines. (They have different 0-bases on the graph). point on graph shows amount of latency for each interrupt. Interrupt is on horizontal axis.
page 14 shows interrupt latency, under load.
All results are shown normalized, to avoid disclosing actual numbers for the CELL processor and hypervisor.
Stair-step results in the graph are from hdparm being run in a loop. Sometimes hdparm was putting load on the system, and sometimes it was not (at regular intervals).
page 15 has previous results, with non-rt kernel with bug.
page 16 shows corrected results
page 18 - load is netperf
page 26 - send performance of nonRT kernel is used as baseline for normalization. Measurement is of network performance (with several different configurations). Result of good performance for non-RT kernel, but with interupt threading is not expected.
