Marc Hamilton's Weblog: Marc Hamilton's Weblog

First we grabbed a Sun Fire server with four Opteron processors and loaded up the latest Solaris engineering build. Then just for fun we started the nightly Solaris kernel build which starts up a few thousand compile jobs. Then just to make sure we were keeping the CPUs busy we started up a background job that throws 240 processes on the system. These background jobs were run at priority 0 so they only run when CPU cycles are available. This was good enough to generate a load average of over 3000 active jobs:

# uptime 8:05pm up 4 day(s), 16:09, 2 users, load average: 3689.85, 3590.41, 3248.41

Then to test the real-time performance we used a simple program we call latstat that measures interrupt latency, dispatch latency, kernel-user context switch latency, and total latency. The real-time task is running on CPU 0 in a single CPU processor set with interrupts driven away and waits for a high level timer interrupt. It takes measurements of its progress from waking up until it returns to user land. Here is the full output from the lastat tool. The best page to look at is the last one. This is simply the delta between the time the interrupt was to be delivered and the time the application was running in user space. This graph is over 300 million points. The mean is 4 microseconds and worst is 32 microseconds. There are roughly 300 points out of the 300 million that are in the range of 13 microseconds to 32 microseconds. While there is no hard definition for "real-time", operating systems that average > 1000 microseconds response time are generally not considered realtime and "hard real-time" embedded operating systems like vxworks generally get you in the 10 microseconds range.

I'd challenge any commercial Linux distribution to beat those results, you can even use an unloaded system! I'd be happy to provide a copy of our latstat code if anyone is up to the challenge.