6533 PCMCIA card maximum speed

[Buffning]

I'm wondering what the maximum speed of the 6533 PCMCIA card is.  The data sheets show all the benchmarks to be in the MHz range.  I'm running the example program (DIdoubleBufPatternGenExtClock653x.C) for continous pattern input and I get error 10803 at 100KHz and error 10845 at 10KHz.  This seems way too far below the benchmarks to be a real ceiling for the card speed when I"m running on a comparable computer (1.8GHz processor, Windows xp, 512 RAM).  The benchmarks were done in Labview.  Will labview run that much faster than c++?  Is there any way to increase the speed at which the card operates?  I understand that the benchmarks are system dependent and such, but not running at 100 times slower than the benchmarks seems a little off.  I'm also confused as error 10845 seems to indicate that the bus can't run fast enough, while error 10803 seems to indicate that either the card or the program is too slow.  It seems that if the bus is too slow for 10KHz, it should also be too slow for 100KHz.

Any help would be appreciated,
Mark

[Jeff_T.]

Mark,

The PCMCIA 6533 has the ability to transfer data in the MHz range in very specific conditions.  There are two main factors that can significantly affect performance of the card during an input task.  The card only has a 16 sample FIFO and the card must use interrupt transfers (as opposed to DMA).  The speeds your are seeing are not a result of LabVIEW vs C++, rather your processor is constantly having to pull data off your FIFO after every 16 samples.  This is alot of overhead and greatly decreases the speed in which you can fill your FIFO with data before you overflow the buffer.

I have performed digital input tasks with the PCMCIA 6533 with a fairly old laptop and was able to run at around 9-10 kHz on a very simple program.  This is by no means an official benchmark but I offer it just to give you something to compare to.

Regards,

Jeff Tipps
Applications Engineer
National Instruments

[Buffning]

Thanks for the info.  I was wondering if you went through setting a higher processor priority for your program and if that helped at all.  I'm set it to realtime priority so the data transfer was the only thing the processor was handling and it still only ran for about 1 min before overflowing at 10KHz.  i guess that shows me my answer, but did you happen to try this too?


Thanks,
Mark

[Jeff_T.]

Mark,

I did not try it but give it a shot and please post your results.  I would be interested to hear if it helps!

Jeff Tipps
Applications Engineer
National Instruments

[Buffning]

I used the sample program DIdoubleBufPatternGenExtClock653x.C and changed the buffersize to 10000 and number of buffers to read to 30.  I'm on a Windows XP based machine with 1.6GHz processor, 512 RAM.  Working in normal mode I got a maximum speed at 4.5KHz.  Setting the process priority to high and the thread priority to Time_critical, I got 8.5KHz.  Setting the process priority to RealTime (warning: you can't even move the mouse much less anything else in realtime.  make sure there are no infinite loops before trying this) and the thread priority to Time_critical, I got 9.5KHz.

On a side note, that is really confusing me: The more buffers I tried to take in, the slower I had to make the clock in order to successfully take in all the buffers.  For instance, if i took in 5000 buffers as opposed to 30, then realtime mode only worked when the processor was at 4KHz.  at 9.5 KHz, it ran for like 3 min then crashed.  At 6 KHz, it ran for like 5 min then crashed.  I'm not sure why running the program for longer slows down the process, but it appears to.  I'm not allocating any more memory by increasing the number of buffers to read unless the DIG_Transfer is using up memory in some way.  The processor is still 100% dedicated to the card so i'm not sure why time should effect it.

Mark