Re: Real-time pre-emption kswapd/kscand questions

From: Tom (tom2ll2_at_hotmail.com)
Date: 12/01/04 

Date: 1 Dec 2004 08:09:46 -0800

Hi Michael,

"Michael Blanc" <mblanc@znet.com> wrote in message news:<1101862469.989183@news-1.nethere.net>...
> Tom,
> After I sent off that suggestion, I had some other thoughts. To wit: there
> should be other was to disable ethernet transactions without low-level
> messing around - but you would almost certainly have to have root
> priviledge. Options might be:
>
> 1> Reconfigure the FDDI controller to ignore all incoming packets -
> essentially to go into a state of absolute quiescience during the 60 second
> period - and then restore normal functioning after. Or
>
> 2> Uninstall the driver which handles the controller, then re-install. This
> is klunky, but should work, hopefully without a reboot.

Good suggestions, thank you. I will continue to try out things.
>
> But I think that we agree in general. The approach is not to move around
> some basket which catches the falling fruit, but to uproot the tree
> altogether (and replant in 60 sec).
>
> I am curious - are there other users on this one linux machine besides
> yourself and the data acq task? Are the A/D samples obtained through
> interrupt, or polling?

No, there are no other users. The A/D app runs as root renice'd to
-20. The A/D card is armed for trigger then the app sleeps until the
sample set is collected. So it is interrupt driven, however, I have
tried polling, but without any difference in results. The whole
process is repeated for the 60 seconds. Here's some psuedo code to
illustrate:

struct sampleSet {
    struct timeval t[60000];
    short buff[60000*256];
    struct oh overhead[60000]; // various overhead data required by
A/D card.
} sampSet;

struct sampSet* ss = &sampSet;

// the overhead is large. The total size allocated is around 128 MB

// for 60000 triggers @ 1KHz ==> i.e. 1 min
for( i = 0, index = 0; i < 60000; i++, index += 256 ){

    // timestamp this buffer
    gettimeofday(&ss->t[i]);

    // arm the A/D immediate return
    acquire();

    // sleep til sample set collected sample set size is 256 samples
at 250 MS/s
    // This sleeps for approx. 1.024 usec
    waitForEndOfAcquisition();

    // DMA transfer out of A/D card takes approx. 40 usec
    readData(&ss->buff[index], &ss->overhead[i]);

}

// write timestamps and buffer to disk
for( i = 0, index = 0; i < 60000; i++, index += 256 ){
    fwrite( &ss->t[i], ... );
    fwrite( &ss->buff[index], sizeof(short),256, ... );
    fwrite( &ss->overhead[i], ... );
}

As you can see, and as "top" confirms, CPU utilization is low, around
2-5%. I have also confirmed (via scope), the trigger source is
constant.

Every 23-25 seconds, kscand/Normal daemon wakes up and takes 5-15 ms
to run. Causing my delta's (ie t[i+1] - t[i]) to exceed 1 ms. I'm
currently flailing with sysctl and trying to tame/understand the
kscand/Normal behavior. I'm also trying to determine if kscand/Normal
is the problem or an interrupt state (such as ethernet that happens to
occur during kscand/Normal) is causing my headaches.

I found the following post very interesting and similar to my
situation:
http://groups.google.com/groups?q=kscand/Normal&hl=en&lr=&safe=off&selm=fa.mrdk84l.bgkkq3%40ifi.uio.no&rnum=1
I have contacted the author and, hopefully, he can provide some
additonal insight into this problem/situation.

I'll keep posting as long as anybody is listening...

Thanks for your reply,
Tom

Loading