Wednesday, June 07, 2006


Performance in action

Yesterday I've written the first combat plugin for performance.gauntlet called PfLatencyPlugin. It finds the longest interval between local APIC timer's interrupts on CPU 0 and draws a horizontal green line covering that interval. The most natural test was to try to determine the cause of the worst latency case that I know to date which is latency introduced by nVidia's graphics driver. And an instant success followed! I've prepared a screen composition to illustrate the process. The cause of the delay is x86's wbinvd instruction.

There's a recent discussion on the topic here:

I'm going to try to overcome this in a way similar to the one proposed by Bernhard: to prefill the cache with a necessary lot of data to make it synchronized with the main memory so that wbinvd would not take long to complete.

Tuesday, June 06, 2006


Equidistant task solved

I've mentioned equidistant correction plans here. It was implemented last summer. The correction is done at the program description level in terms of lines and curves. Tunable corner cases and transitions, instant configurability over myconf, works fine. Here is a shot of it.

Monday, June 05, 2006


Performance tuning

I've just put a bit of love into Performance. Here is the screenshot of performance.gauntlet. I take the trace with the following commands:

echo 1 > /proc/performance/enable
# Do something special
echo 0 > /proc/performance/enable
cp /proc/performance/trace ./
gauntlet trace

Copying from proc is required because gauntlet mmaps the file and procfs doesn't support mmap. I'm looking forward to some better way of accessing trace data that would allow direct mmap without copying.

Then gauntlet window appears where the trace is displayed in a timeline horizontally and can be moved and zoomed. A thick yellow marker line follows mouse pointer and in a text field at the bottom there is a list of events covered by the marker. It's quite convinient. The only thing left is to add some heuristics to determine bad high-latency places and to highlight them.

Sunday, June 04, 2006


Long live GRelay

Last winter I tried to prepare packages for the first public MyNC distribution. I soon realized that privately-patched OmniORB was a killing dependency: it builds enormously long, it is uncertain how to distribute IDL's properly, and I've failed to write that I would be satisfied with. CORBA took its evil hands too deep into my code and turned simple things into complicated beasts. So I've decided to throw CORBA away from MyNC and replace it with something home-grown. The new middleware is called GRelay, it's simple, features straightforward design, textual protocol (direct GRelay shell scripting? - yes) and lacks any kind of IDL and IDL compiler. MyNC porting to GRelay is not finished yet but I've already tested GRelay in a file-server called "filewar" written as a student hometask. It's a bit boring to write client and server stubs for GRelay objects manually but overall simplicity worths it and MyNC interfaces are quite compact anyway.


On the way to 1.0

First, the project now has a stable name: "MyNC" which stants for "My Numerical Control" - quite simple, really.
Debugging a real-time patch for SMP Linux 2.6 is pain. It looks like I've just finally assembled something stable called linux- It doesn't show great timings yet, I know it can perform better, but this is the only stable version so far. In the version string "-rti" stands for "Real-Time Interrupts" and "-pf" stands for "PerFormance", a tracing toolkit somewhat similar to Linux Trace Toolkit. The main purpose of Performance is to catch real-time-consuming critical sections to get rid of interrupt latency. -rti-pf is not critically important though, MyNC can easily be ported to any real-time environment like RTAI (or even lower-level ADEOS) and L4/Linux. I even considered the possibility of running MyNC on MINIX 3, but lack of threading support in MINIX blocks the effort.

This page is powered by Blogger. Isn't yours?