RTAI LiveCD + DB

Fillod Stephane stephane.fillod at thomson.net
Thu Oct 28 20:33:59 CEST 2004


Dimanche 17 octobre 2004 00:57, Panagiotis Issaris ecrivait:
>On Sat, 2004-10-16 at 12:49, Panagiotis Issaris wrote:
>> Several questions/problems here:
>> * Are the shown applications good for generating an artificial load?
>>   I normally use pingflooding as well. Should I add it to the test? Any
>>   other apps I could add to the test?

Let's think of it. Instead of trying random applications to put load on,
why not wondering what is the real latency killer, and as we use to say,
here, "mettre le doigt où ça fait mal" (put the finger where it hurts)?
This can be answered by knowing your computer achitecture.

As far my understanding goes, here are some RT latency killers:
1) freezing-cold I-Cache and D-Cache
2) freezing-cold I-TLB and D-TLB
3) CPU currently receiving exception (received but not handed out yet)
4) bus contention with busmasters (DMA, ..), if allowed by design
5) any other idea?

The dd trick is a 1) and 2) hitter, and maybe 4) if DMA disk is involved.

Case 1) can be implemented with infinite call to cacheflush(2), if available.
The case 2) can be addressed with a TLB/cache wash out agent like the
"dirty" snippet (original idea from feu Rene Cougnenc):

        char *p = (char*)malloc(PLENTY_OF_MEGABYTES);
	  for (;;) {
		int i;
	        for (i=0; i<PLENTY_OF_MEGABYTES/PAGE_SIZE; i++) {
                *p ^= i;    /* make the page dirty */
                p += PAGE_SIZE;
		  }
        }

Note: this works out only the Data side of cache/TLB.
If user-land load generators are not efficient enough, we can devise
a regular(non-RT) Linux kernel module to call directly the cache and tlb flush.


> Well, there is still the option to ask LiveCD users to connect pins 9-10
> of the parallel port on their box using a paper clip, but, well... ok.

What not? Just make it optional, with a cleverish autodetect mode,
and a safety net to remind people to remove the paper clip :)

However, that would be the best solution to generate interrupt load
and hit the 3) above. To exercize exceptions, another solution could be
to execute bad code ala crashme or FPU/buserror/faults/etc. in a loop
with masked signals.

The case 4) can rely on "hdparm -u1 -d1 /dev/hda && dd if=/dev/hda ..",
but the contention (to access DRAM) will be limited by the bandwidth
of your drive. Hardrives would be better than CD drive in that respect.
Network-wise, you need a GigE to have a network traffic sustained enough.
Unfortunately, there's no high performance standard DMA under x86 arch's
to program an on-purpose bandwidth-eater in a kernel module.


Finally, we can then mix all these sources all together.

All in all, this would not give a realistic load, but we are chasing 
worst-case latencies, aren't we? The most insanes would draw a contest
on this :*)

Please feel free to correct my sayings if wrong, and comment as needed.


Thanks,

-- 
Stephane




More information about the Rtai mailing list