resending to list - accidently sent to EBo only...

EBo wrote:

> 
> Here is my experimental setup...  open up two windows. 
> 
> In the first run either the configuration program or the latency tests.  The
> test writes out the header block and just sits there.  I mean it does not
> appear to run the thread at all.

I take it you are running the RTAI latency test?  (We also have our own,
it uses HAL and is more newbie friendly.  For your purposes the RTAI one
is at least as good, but I want to make sure we're on the same page.
Your description of a header makes me think you are running the RTAI one.)

The RTAI test is supposed to print one line of results every second.  If
you start that test and don't see output like that, something is
seriously borked with your realtime setup...  I don't even know where to
suggest you look - I've never encountered such symptoms.

>  No go and run a CPU hog in the other
> terminal.  My hog of choice is "top -d 0" which grabs process info with a 0
> second period and just start flashes.
> 
> Once I start the second process, the first (RT) starts chunking out the
> latency info at 1 second intervals.  Now for the really interesting part. 
> Kill the first proces.

Really weird.

> Killing the CPU hog process causes the RT thread to stall again.  Until I
> restart CPU hog.  Every once and awhile it will give another tic, but not
> continuously as expected.  So, while the 1 second wait does check the latency,
> control never goes back to the calling process to get ready for the next tic.
>  This completely disrupts the actual flow of the latency code and does not
> really check it for overall smoothness of the requested tic's -- which has
> huge implications with regard to however the tool velocities of a machine
> which is driven by a processing thread on a CPU with this problem (and I would
> call it a bug).  It may just be some weirdness with my kernel config, but I
> personally consider this a warning sign...

You've completely lost me with your description of calling process and
latency code.  I really don't know how the RTAI latency test works, so I
can't even speculate on what it means when there is no output.  It could
mean that the userspace part which prints results is blocked, or that
the realtime part isn't delivering any results to be printed, or ....?

IMO, at this point the cpu hog results are a red herring.  If the test
isn't spitting out a row of numbers every second as soon as you start
it, something is busted with a capital B and all bets are off.  I
misunderstood your initial message and thought you were just getting bad
results, not no results at all.

What kernel are you using?

Regards,

John Kasunich


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to