Intel acquires OpenedHand: good news for TimeSys

The announcement today that Intel has acquired Opened Hand is good news for anyone building a multimedia appliance with LinuxLink.

More changes to the beta analysis applet

When I added the code to sort the results table on any reasonable column, I noticed that the priority column sorted the tasks backward. Hmm. So I fixed that.

Surprisingly, the analysis code did not totally explode, though some results were a bit strange. (Most analysis code assumes that the tasks are sorted so the higher priority tasks are at lower indexes.) I fixed that. Now sorting the output table and sorting for analysis use different sort methods.

tsrpmv: making tsrpm easier

I use tsrpm a lot but find its output hard to interpret and it's invocation difficult to remember. Additionally I was always passing options to tsrpm like --verbose, so I wrote a wrapper script to automatically add that to any tsrpm command. I call the script tsrpmv, short for tsrpm verbose. It can be downloaded from http://www.timesys.com/blog_files/tsrpmv. Mark it executable and place it in /opt/timesys/bin.

Latest on the Beta Applet

Today I made two changes to the applet:

1. Clicking on the header for a column will sort the results table on that column. No, clicking on it twice won't sort it in reverse order. :-)
2. There's now an exponential time algorithm for finding a feasible set of priority assignments for MP systems. The applet will try this algorithm if the Audsley's algorithm (heuristic) fails and there are no more than 16 tasks.

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.