adam li wrote: > Thanks for the suggestions. > > I am using Blackfin 533 on the STAMP board. The core frequency is 398 > MHz.These data are got when there is not special workload, only uClinux > running. > > I tried to run "latency" test in Mode 0 (user space task) for 60 sec, > with the "calibrator" as work load, this time the worst case schedule > latency becomes 82 us.
Dare to run the test for a longer period than just a minute. It may happen that certain events (IRQs) hit your RT test only vary rarely, but still cause a few more us latency. Basically, this is one reason why you should run multiple i/o loads in parallel, as each of them can delay your critical real-time job a bit more. > > As you mentioned: > > ">Yes, Xenomai is a hard-RT system. But this doesn't depend on a > specific >> worst-case latency number, rather on the fact that a hardware-dependent >> upper limit can be provided that is independent of the (here:) Linux load" > > Can I understand like this: Given the hardware and the workload, the > upper limit (worst case latency) is "determinative", regardless of what > is happening in Linux? Yes. Xenomai's worst-case latencies do not depend on what kind of programs are running under Linux and what Linux services they use, they only depend on the hardware devices (IRQs, buses, etc.) they are using. > > But still another confusion, as we can see from the test result, given > the hardware and the workload, each time running the "latency" test case > will result in an average latency and a worst case value, but how can we > "make sure" that using such hardware and such workload, the worst case > latency is "sure" to bellow certain upper limit? In other words, is it > possible that in some case, the worst case latency may go beyond the > observed upper limit? Or can I say that, there is such possibility, but > the probability is rare (statistically). > In theory, by a complete static code analysis in combination with a good model of all involved hardware components of the system. But this is impractical for such complex systems. Therefore, one tries to reduce the amount of code to analyse and then derives a rough model from it. Xenomai helps here by decoupling the RT core from Linux with all its applications. Furthermore, one defines a simplified hardware model for a specific system. And then tests are performed to measure worst-case latencies of individual components or the whole application to verify the model and generate input for projections of non-testable scenarios. Well, in practice, one only measures a lot of stuff over a real long time, takes the numbers, multiplies them by 2 (or more), and prays that this will be good enough. :) Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
