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 running), 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 1.0-01 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 + calibrator) was executed manually, it may not be the same. -- Stephane _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
