Daniel Walker wrote:
On Mon, 2008-01-28 at 10:32 -0800, Max Krasnyanskiy wrote:
Just this patches. RT patches cannot achieve what I needed. Even RTAI/Xenomai
can't do that.
For example I have separate tasks with hard deadlines that must be enforced in 50usec kind
of range and basically no idle time whatsoever. Just to give more background it's a wireless
basestation with SW MAC/Scheduler. Another requirement is for the SW to know
precise timing
because SW. For example there is no way we can do predictable 1-2 usec sleeps.
So I wrote a user-space engine that does all this, it requires full control of the CPU ie minimal
overhead from the kernel, just IPIs for memory management and that's basically it. When my legal
department lets me I'll do a presentation on this stuff at Linux RT conference or something.
What kind of hardware are you doing this on?
All kinds of HW. I mentioned it in the intro email.
Here are the highlights
HP XW9300 (Dual Opteron NUMA box) and XW9400 (Dual Core Opteron)
HP DL145 G2 (Dual Opteron) and G3 (Dual Core Opteron)
Dell Precision workstations (Core2 Duo and Quad)
Various Core2 Duo based systems uTCA boards
Mercury AXA110 (1.5Ghz)
Concurrent Tech AM110 (2.1Ghz)
This scheme should work on anything that lets you disable SMI on the isolated
core(s).
Also I should note there is HRT (High resolution timers) which provided
microsecond level
granularity ..
Not accurate enough and way too much overhead for what I need. I know at this point it probably
sounds like I'm talking BS :). I wish I've released the engine and examples by now. Anyway let
me just say that SW MAC has crazy tight deadlines with lots of small tasks. Using nanosleep() &
gettimeofday() is simply not practical. So it's all TSC based with clever time sync logic between
HW and SW.
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
