lkml.org 
[lkml]   [2008]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [CPUISOL] CPU isolation extensions
    Hi Daniel,

    Sorry for not replying right away.

    Daniel Walker wrote:
    > On Mon, 2008-01-28 at 16:12 -0800, Max Krasnyanskiy wrote:
    >
    >> 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.
    >
    > I don't know if it's BS or not, you clearly fixed your own problem which
    > is good .. Although when you say "RT patches cannot achieve what I
    > needed. Even RTAI/Xenomai can't do that." , and HRT is "Not accurate
    > enough and way too much overhead" .. Given the hardware your using,
    > that's all difficult to believe.. You also said this code has been
    > running on production systems for two year, which means it's at least
    > two years old .. There's been some good sized leaps in real time linux
    > in the past two years ..

    I've been actually tracking RT patches fairly closely. I can't say I tried all of them but I do try
    them from time to time. I just got latest 2.6.24-rt1 running on HP xw9300. Looks like it does not handle
    CPU hotplug very well, I manged to kill it by bringing cpu 1 off-line. So I cannot run any tests right
    now will run some tomorrow.

    For now let me mention that I have a simple tests that sleeps for a millisecond, then does some bitbanging
    for 200 usec. It measures jitter caused by the periodic scheduler tick, IPIs and other kernel activities.
    With high-res timers disabled on most of the machines I mentioned before it shows around 1-1.2usec worst case.
    With high-res timers enabled it shows 5-6usec. This is with 2.6.24 running on an isolated CPU. Forget about
    using a user-space timer (nanosleep(), etc). Even scheduler tick itself is fairly heavy.
    gettimeofday() call on that machine takes on average 2-3usec (not a vsyscall) and SW MAC is all about precise
    timing. That's why I said that it's not practical to use that stuff for me. I do not see anything in -rt kernel
    that would improve this.

    This is btw not to say that -rt kernel is not useful for my app in general. We have a bunch of soft-RT threads
    that talk to the MAC thread. Those would definitely benefit. I think cpu isolation + -rt would work beautifully
    for wireless basestations.

    Max


    \
     
     \ /
      Last update: 2008-02-04 07:57    [W:8.663 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site