Wolfgang Grandegger wrote:
>> Load for klatency/latency was ping flooding on FCC (piece of cake),
>> and cache calibrator. IMHO, we can do nastier.
>You mean the cache calibrator from http://monetdb.cwi.nl/Calibrator/? I
>tried it on my Ocotea board and it increased the max latency for 25 to
>30 us.

Yes, that very one. In this case, it has been used as a cache trashing
load generator. But IMHO, this Calibrator should be better used in the
Benchmarking Plan to get L1/L2/RAM access latency figures (w/o RT
and offer one more correlation against RT latency results.

We can afford a better cache trashing load generator. Earlier this year,
I proposed flushy(tm) [1], but as Philippe suggested, we can do better.
Flushy should be rewritten as an ADEOS layer, inserted just in front of 
Xenomai in the pipeline. This way, we would be sure the caches
are dead cold when Xenomai enter its domain. Using tools like OProfile,
it should be possible then to track cache misses, and fix them 
by prefetching, where available.

[1] http://rtai.dk/cgi-bin/gratiswiki.pl?Latency_Killer (bottom of page)

Here is the result of my 1.0-01 tests on e500:

$ cat /proc/ipipe/version

SWITCH without load:
RTH|     lat min|     lat avg|     lat max|        lost
RTD|        3660|        3690|        8070|           0 1.0-00
RTD|        4620|        4740|        8730|           0 1.0-01

KLATENCY with load:
RTH|-----lat min|-----lat avg|-----lat max|-overrun|
RTS|       -7350|       -5715|        6420|       0|    00:03:17 1.0-00
RTS|       -6150|       -4384|       12180|       0|    00:03:13 1.0-01

LATENCY with load:
== Sampling period: 100 us
RTH|-----lat min|-----lat avg|-----lat max|-overrun|
RTS|       -6930|       -4260|        8700|       0|    00:08:06 1.0-00
RTS|       -5670|       -4620|       12930|       0|    00:12:39 1.0-01

That's weird. Figures are worse, but since the load (ping -f +
was executed manually, it may not be the same.


Reply via email to