DVD authoring

Last week I was finally able to create a DVD-Video with ffmpeg which played on both my parents Sony DVD and my own Sony DVD player without any problems whatsoever. My previous tries ended with DVD which showed either horrible green artifacts or severe synchronisation problems. With last weeks CVS tree, it works fine.

So, the create a DVD-Video the output of ffmpeg can be fed directly to dvdauthor, no de-re-multiplexing of MPEG streams is necessary. And what's even better, on my Athlon XP 2000+ system, its encoding is faster then real-time; encoding to DVD-Video compliant MPEG-2 only took 75% of the running time of the video.

Java middleware performance

Read an interesting paper on Java middleware performance which reaffirms my thoughts on this topic. Webservices are awfully slow, CORBA implementations vary wildly but all outperform the webservices. Fastest was the Orbacus ORB, second was RMI, slowest was SOAP, one but slowest was XML-RPC. The higher level abstractions such as CCM and EJB caused overhead. CCM on CORBA outperformered EJB on RMI. Seems that just as SOAP and XML-RPC, EJB implementations JBoss and JOnAS are awfully slow.

3D visualisation

While discussing Blender animation on IRC, I was pointed to a Python 3D engine called Soya.

Poekie

Just a few minutes ago my dad told me that my cat Poekie had been killed by a car. Here's a picture of Poekie.

some more pictures of Poekie

We had saved him twice before, but aparantly I couldn't save him this time :-(

We found him as a kitten and fed him and gave him a home. For years, everything went fine, until last summer when he got bitten by a rat. He almost died from the infection... We didn't notice that he had a wound, because his fur is so thick and he didn't complain much about it. Just the lack of appetite disturbed me.

Now, apparantly last night he crossed the street and got hit by a car.

Internet phone

Today a colleague of mine pointed me to a Internet phone application called Skype. It gave it a try and it sounded remarkably pure and clear. They apparantly had just released their GNU/Linux version today.

Bochs

Not all bugs are equal. Some are easily located by just looking at the code, some by watching the execution flow. Some bugs are really hard to locate and a debugger can help in tracing those.

When you're working on a project which involves modifying Linux kernel code, you'll have to be able to debug the Linux kernel. This is harder then debugging normal userspace applications. But luckily, the Linux community has provided some decent tools such as the various kernel debuggers and f.e. DProbes.

When you're programming RTAI, and you're bitten by an RTAI kernel bug, you're in big trouble. The Linux kernel debugging tools in general don't just work together with RTAI's ADEOS patch. So, there's no real tool to aid you. The best thing that might happen if something goes wrong is a kernel Oops, which you can try to trace and fix (See this Oops tracing howto).

Unfortunately, some bugs are really mean. They might cause a crash without an Oops or they might for example give you no backtrace at all.

One possibility for debugging such ugly beasts is a PC emulator such as Bochs. The Bochs PC-emulator has an integrated debugger. Unfortunately, Bochs is really slow. Some say, the emulation system runs about two hundred times slower then your real system.

Nevertheless, I tried to use it to debug RTAI/LXRT applications, but unfortunately, RTAI/LXRT applications don't run stable yet using Bochs.

CORBA porting adventures

Because of issues with the TAO 1.3 OCI release, I started the port to 1.4.1 knowing that we would need that port anyway because of CIAO. The initial direct try from 1.3-OCI to 1.4.1-DOC was a failure,
too much had changed (9 versions) and apparantly I made a mistake somewhere...

The next try took a lot more work, because I ported to every successive version from 1.3-OCI to 1.4.1-DOC. So, from OCI's 1.3 release to the DOC group at Washinton University 1.3, to 1.3.1 DOC, and with every version in between to the final 1.3.x release of the DOC group 1.3.6-DOC. Then the porting continued to the major new DOC group release 1.4.0 and finally to 1.4.1-DOC.

Now, to be able to merge, I'll have to port it to the 1.4.2 CVSUP tree version. And ofcourse, test it extensively.

How to trace a kernel Oops

Since a lot of the questions I answer keep returning to me, I thought I would be useful to set up a FAQ webpage. The first real entry explains how to trace a Linux kernel Oops.

Blending CORBA part 3

This morning I had been testing the scalability of the Blender/CORBA Event Service connection thingy. Unfortunately, it didn't look good. I started to investigate the possible problems and changed the IDL to have lower overhead and better scalability.



Now, I have been playing around with about a dozen Blender objects moving around and rotating according to the coordinates specified by a CORBA server feeding events. So, it seems to work now. There still are some issues though.

I rendered this silly Blender-CORBA animation to a video.

Blending CORBA continued

I finally managed to get a fluent Blender animation which received positional information using omniORB from a TAO CORBA server. It doesn't look impressive at all, since it just shows a simple cube moving around... but the possibilities are endless! :-)


If I make the code just a little bit more general, it should be possible to animate any Blender scene just by writing a CORBA Event Service supplier supplying various attributes for Blender objects.

Blending CORBA

Last Sunday I experimented with using CORBA from within Blender's Python scripting environment. Yesterday, I extended these simple scripts to use the EventService to receive its updated data.

Unfortunately, there appear to be some problems with Blenders Python scripts. For example, even though a particular script ran successfully several times, then suddenly, Blender complained about syntax errors. There were no modifications between the runs and there was no syntax error :-(

TAO 1.3 problems on Linux 2.6

So TAO 1.3 doesn't seem to work on Linux 2.6.

I'm being flooded with futex(0xbffff510, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) messages from strace.

The problem seems to be resolved in TAO 1.4 but using 1.3 is easier since that's the version I'm also using on RTAI. To be able to run a CORBA application, I now have to keep compiling the IDL files with different versions of TAO, which is pretty annoying. So either I start testing the TAO 1.4 port I've been working on monday or I'll have to figure out what is causing the problems with Linux 2.6 and TAO 1.3. Using the old threading library doesn't seem to help. I should reboot using a 2.4 kernel to make sure I'm not hallucinating.

Threading issue

The threading problems were caused by a change of the default stacksize. And yes, some basic functionality has not yet been implemented in NPTL.

NPTL issues

Yesterday, when testing the new TAO/ACE release, I noticed several tests were
failing. I assumed the mistake was ACE's, and debugged it for hours.
Unfortunately, the bug wasn't in ACE, but in the new POSIX threading library for
GNU/Linux (NPTL). This was rather disappointing to me, since I had read nothing
but good about the new threading implementation. The problem occurred because on
thread creation, NPTL just ignores the thread attributes. So, selecting a
scheduler or priority on thread creation doesn't work at all.

Furthermore, I noticed, that the new threading library only allowed me to create
255 threads, while LinuxThreads allowed me to create 1532 concurrent threads.
This is even stranger, as I have read reports on using 100k concurrent threads
with this new threading implementation. Apparantly, somethings wrong here, but I
can't figure out what could be causing this.

And, when I was trying to report these issues to the NPTL developers, I couldn't
find their mailinglist. I could find people referring to it, but I couldn't find
the address :-) Now, for some reason it's called the phil-list... not quiet easy
to associate this with a new threading lib.

gettimeofday_rt

I just ported the gettimeofday_rt I wrote for the previous release of RTAI to the newest RTAI 3.0. It works just fine for the ACE test! :-) Now, there are just some minor issues related to the prefered style of linking... Next up, is the porting of ACE's debug framework.

One thing that's still missing from the RTAI Kilauea tree, is a decent gettimeofday function. I've added an implementation to the stable RTAI tree (Stromboli) earlier, so I'll just have to port that one to Kilauea. Without that patch, some ACE/TAO tests will definitely fail.

Other than that, the ACE debugging code has to be ported as soon as possible. Don't know if it's best to shove the data through a real-time FIFO or to just implement is using rt_printk.

A few weeks ago, our TAO/ACE RTAI (Stromboli) port was starting to show some results. The CORBA benchmarking application I wrote about a year ago, worked on RTAI, both in soft and in hard realtime.

Last week, I started porting our TAO/ACE code to the new RTAI tree, called Kilauea. And about three hours ago, I ran all my (collocated) benchmarking code without any crashes! :-)

Furthermore, the official Collocation test included in TAO also works on RTAI 3.0 in hard realtime without any problems! Yay! :-)

I'm using the benchmarking results to create some charts which I'll post later on, to illustrate the achievable performance with TAO/RTAI.