[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IRQ latency and context switching on mvme5500 (was Re: RTEMS mvme5500 bsp)
- Date: Thu, 28 Jul 2005 14:15:35 -0400
- From: Kate Feng <feng1 at bnl dot gov>
- Subject: Re: IRQ latency and context switching on mvme5500 (was Re: RTEMS mvme5500 bsp)
Peter Dufault wrote:
> Can you also include all the identifying information about the
> vxWorks version, and whether you've modified anything from the
> I've also got a fairly big application running on RTEMS-mvme5500 and
> now vxWorks 5.5. I don't know why Wind River sold my client 5.5, I
> wasn't involved in that, maybe 6.x doesn't run on the MVME5500?
> Maybe 6.x is more up-to-date? If anyone knows, please let me know.
The vxWorks image was built at Diamond Light Source, by Steve Singlton.
His E-mail is included in cc.
Maybe he can tell you which version. However, I am sure the CACHE
is enabled in his copy of config.h.
> FIRST, THOUGH, RTEMS doesn't do anything with the 64-bit counter on
> the PPC, right? That's where I get my timings.
I used the on-board 32 bit counter. clocked rate 133MHZ.
> I can't get to the system to provide full details, but here are a few
> notes from memory.
> 1. The vxWorks distribution has L2 and L3 instruction cache disabled
> from the factory, with a note such as "per Wind River support" in the
> config.h Motorola header file where it's disabled. I've enabled
> instruction cache without noting any problems. Timings are
> particularly bad before that.
> 2. The vxWorks header files are ANTIQUE, and my client just bought it
> last month! gcc is "2.96". The claimed POSIX compliance is circa
> 1995 and even then it doesn't come close. The networking headers are
> particularly bad. I had to put a whole lot of work-arounds in to get
> code that runs on Linux, FreeBSD, RTEMS, Cygwin, and OS/X to work on
> the vxWorks "POSIX" interface.
> 3. With cache enabled the context switch times are still surprisingly
> slow on vxWorks. I'll quantify "a lot" when I can dig up some notes,
> but my biggest surprise was the time between the interrupt semaphore
> post in my ISR and when I was finally in the high-priority task (set
> at PRIOMAX) activated by that semaphore.
> 4. My networking code needed tweeking to get it to work reliably and
> fast on vxWorks. I never could get receives to work in a timely
> fashion unless the receiving end knew ahead of time how much to
> receive, even setting the low watermarks, send and receive buffer
> sizes, etc wouldn't get things working well. I finally gave up and
> started sending a fixed minimum packet size that told what would come
> in the next packet if it didn't fit in the first one. The same code
> is run in all places so that isn't a variable, it probably improves
> it a bit everywhere.
> I'm running a multi-axis control application and I've been doing life
> testing with both RTEMS and vxWorks at the following rates. I'm
> using my own drivers for analog I/O. The first number is RTEMS, the
> second vxWorks. I arrived at these numbers by detecting analog input
> overruns and then backing off a bit and also being sure the UDP data
> is coming up OK (I live with occasional drops).
> Data acquisition interrupt (copies data off PCI board, posts
> semaphore): 22KHz 15KHz
I think you should get a better interrupt rate with RTEMS-mvme5500
version 1.3. --Kate
> Inner loop (fields semaphore, does inner loop, outputs to DACs,
> safety checks, periodically posts semaphore for outer loop, assembles
> data for UDP upload, posts upload semaphore): 22KHz 15KHz
> Outer loop (Fields semaphore, does outer loop processing, profiles
> motions): 2.2KHz 1.875KHz
> IP Command exerciser: (Receives new position command, returns
> status) 50Hz 50Hz
> Command monitor: Runs when a command is typed in.
> UDP Data Upload task: Runs continuously when it can, priority set
> below system network tasks.
> System tasks: The network tasks, and whatever else is started up out-
> Finally, let me note that this was a good exercise - the changes I
> made to get vxWorks faster (networking changes, custom versions of
> semaphores with timeouts since there is no sem_timedwait and POSIX
> timers are of little use on vxWorks) also folded into RTEMS and
> improved my life test rate there from 20KHz to 22KHz.