It sounds like you may be using the 100kHz timebase that is on the 6608. There is also a 20MHz timebase that you can use. If you want to lower the timebase to say, 5MHz, you can use the internal timebase as a source for one counter, and then perform an operation to divide it by 4, and then use that as a source for a second counter, which you will use for the system.
I haven't changed the timebase settings. The hardware side of the operation seems to work fine - I can get 50 ns resolution on the counter operations, so I'm assuming that's using the default 20 MHz timebase.
The problem I'm having is on the software side - getting the DMA to move the data from the counter into memory. It's a VERY slow process. As long as the hardware is working correctly, what effect would the timebase have on the DMA transfer?
Do you perform your AI reads along with your counter operations? If so, I'm curious to see what results you would get if you only did the counter operations. Also, are you doing any other data processing immediately after acquiring from your counter? That also may cause some slowdown.
I am having a very similar problem so I'm wondering how you resolved it. I have a PXI chassis with 12 4472 cards, and I can read from all of them at 32KHz no problem, but when I simultaneously try to read buffered events from two counters on a 6608 card on the same chassis, it runs for a few minutes with no problem, and then throws a 10920 error claiming that I don't have the bandwidth to keep up. I don't get it!
I think the difference in bandwidth here is really due to size of the FIFO's present on each device. The 6115 has either a 16 or 32 Mega-Sample FIFO for analog input. If one of the 6115's isn't granted usage of the bus for a "large" amount of time, it can absorb this by backlogging the data into its FIFO until it is granted the bus, at which time the DMA controller will move the data to host memory before the FIFO overflows. The same is not true of the counters on the 6608. Each counter on the 6608 has an effective FIFO size of 2 Samples. This means at high sampling rates, the 6608 cannot withstand "large" amounts of time without being granted usage of the bus. How fast you can go before the counter FIFO overflows is going to be system dependent, but 200 KHz is in line with results I have observed. If you need to go faster, you can use two counter measurement methods, but you will sacrifice accuracy for speed. For example, by dividing down your input signal by 4, you will be able to go 4 times as fast, but your accuracy will also decrease by a factor of 4. You'll have to weigh the requirements of your application to determine if this type of trade off is acceptable.
Yes, I've been referred to this article many times. But none of the reasons seems to apply. First, I am definitely using DMA transfers, not interrupts. Second, the signals that I am using as sources and gates are all internal to the chassis, namely, the timebase of the 6608 as the source and the RTSI3 line as the gate. Finally, I am nowhere close to the peak sustained throughput of the PCI bus (I'm trying to push 10MB/sec), at least I don't think so.
One interesting clue is that everything works quite robustly if I acquire with the 4472 cards alone and transfer the results via DMA, OR if I acquire buffered events with the 6608 card and transfer via DMA. But if I do both at the same time, the 6608 throws -10920 errors, even though the incremental throughput is tiny.
Has anyone else ever seen this kind of conflict on a PXI bus?