I wonder if non-RM/DM priority assignment is really better for MP

The example in my previous post is, I think, typical of the problems used to show the nastyness of scheduling for a multi-processor. It has three tasks:

• t1 uses 80% of a processor with a period/deadline of 100.
• t2 uses 50% of a processor with a period/deadline of 40.
• t3 uses 25% of a processor with a period/deadline of 40.

Multi-Processor Response Time Analysis

The beta analysis applet now supports the multi-processor response time analysis I've been writing about. To me, a graph of response times gives a better feel for the system than simple feasible/infeasible answers.

Deadline monotonic priority assignment doesn't seem to "work" for multi-processor, so I'm trying Audsley's algorithm on MP. I haven't thought about it enough to know if it will always find a feasible priority assignment if one exists, but it does seem to work.

TSRPM and %pre/%post scripts

RPM packages will many times have %pre or %post scripts embedded in them. These scripts are supposed to be run before or afte the package is installed or upgraded and do things like set up specific configurations.

When creating an RFS, tsrpm can't run these scripts perfectly because your RFS is for a different architecture and those programs won't execute natively on your x86 host. So tsrpm tries to execute a native version, telling it to operate inside the RFS if it can. This process is problematic and doesn't always work.

Response Time Analysis for MP systems!

Ted Baker (a CS professor at FSU) suggested I look at a paper by Bertogna, and Cirinei from the 2007 RTSS that pushes the state of the art for RT analysis of MP systems. I can't find a fully-accessible version of the paper on-line but here's the ACM portal page for the paper. I'm a bit excited about this new analysis algorithm.

checking RPM dependencies quickly

tsrpm is great for cross-compiling but because it is implemented primarily as a bunch of perl scripts, it handles certain tasks slowly. One of those tasks is dependency checking.

Dependencies can be just as easily checked using plain vanilla rpm. Put all the RPM files you want in your RFS inside a directory and run this on the command line to check for missing dependencies:

$ rpm -Uvh --test --ignorearch *.rpm

The RI download page has new stuff

It has version 5 of the Alpha RI for RTSJ version 1.1. The major 1.1-related changes are a re-designed API for phasing control and an API that supports setting processor affinity for Threads (Java, RT and NHRT) and bound async event handlers. It also has default affinities that apply when it doesn't make sense to inherit affinity and for unbound async event handlers.

It also has version 6 of the 1.0.2 RI. This is a bug fix release. The main bug fixes have to do with the interactions between ATC and locking.

Kindle

My wife gave me an Amazon Kindle for Fathers' Day. By this time the initial excitement has worn off so I can comment calmly, and it's a break from real-time, so...

Getting RPMs using wget

I have a machine at my desk that's mainly for administrative tasks (GUI, browsing, e-mail, etc.) and a different machine that's purely dedicated to development. I generally ssh from my main box to my dev box, and don't like to keep a GUI or a browser on that box at all.

Non-embedded real-time problems

Any problem with a deadline is a real-time problem. If missing the deadline is so unacceptable that it's not worth talking about recovering from missing a deadline the problem is a hard real-time problem.

Here are some examples from outside the embedded computing world:

RTSJ Reference Implementation -- update coming soon

I'm getting near to a big RI update:

• for the 1.0.2 RI. Bug fixes
• for the TCK. A major update release
• for the 1.1 Alpha RI. The big change is processor affinity. This version of the RI is able to set processor affinity for Java threads, Real-time threads, and bound async event handlers.

The major bug fix, shared by the 1.0.2 and Alpha 1.1 reference implementations, is in the handling of ATC when a thread is blocked waiting in a synchronized statement.

These updates will probably appear on the RI download page late this week.