Since we have two subjects on this topic, I'm going to try to answer both questions as completely as possible here.
Re-arm time is not normally affected by PCI bandwidth. So the digitizer should be able to acquire and store the waveforms just fine, but you may be limited in how long it can sustain that based on how much memory is on the device and how fast you are able to retrieve data.
Normally each channel and record fetched from a digitizer involves starting and stopping a transfer of data from the onboard memory of the device to host memory. That is, the data is copied on demand because the device can often produce data at a rate that far exceeds the bus bandwidth of the host, and only the requested data is transferred even if many times that are actually stored on the device. This introduces some transactional overhead. In NI-Scope 3.3, because of feedback from customers wanting to get multiple records off the digitizer as fast as possible, we added an optimization that made it possible to coalesce these reads into a single board->host transaction to reduce the overhead.
A normal digitizer acquisition tries to maximize the available memory for a record to make the fetch position more flexible. For example, if a digitizer has 8MB of memory per channel, and you configure the digitizer to capture one record of 1000 points - all 8MB are used for buffering history until the reference trigger occurs (typically the configured analog edge trigger). By using all the memory, the user can still fetch more history beyond the length of their acquisition - perhaps back to the start of acquisition - as long as the data they want to look at has not been overwritten yet. If the user specifies more than one record, the available memory is split evenly and maximally across all configured records.
The multirecord fetch optimization reduces the transactional overhead by grabbing more data in one pass (including some extra data that the user did not request). This is only enabled if the amount of excess data is small. This can often require the user to configure the digitizer to "Enable Records More
Records than Fit in Memory" because the onboard format of data is more
compact - it does not spread records out, it allocates a record the minimum size of memory to contain the requested record size, rounded up to the hardware's natural boundaries.
With these optimizations enabled, depending on the original size of fetch and the number of records being fetched at a time, users can see dramatic improvements in the effective transfer rate. The exact rate is situationally dependent, and if you would like more specific numbers before buying a system, I'd suggest escalating the request through your salesperson. However, multirecord fetch rates that approach the limits of the bus bandwidth are typical.
This optimization is available on all SMC devices except for the 5105 (presently the 5122, 5124, 5142, 5152, 5114, 5922). The data format is slightly different on the 5105, so the optimization is not yet available for it - although it is likely that it will be available in a future release of NI-Scope. If you have a 5105 and are interested in evaluating performance of this optimization before it is generally available, again - please escalate that through your salesperson.
So, for a LabVIEW user wanting to use this - I would recommend testing your application with the niScope property node "Horizontal->Enable Records > Memory" set to True. The C attribute is NISCOPE_ATTR_ALLOW_MORE_RECORDS_THAN_MEMORY. This will also disable warnings about configuring the digitizer for an acquisition it cannot store completely in onboard memory, but will enable compact storage of the records. This property also allows you to free up memory for new records by fetching them out of memory while the acquisition is in progress, enabling you to fetch say 1 million records on a device that only has onboard space for 100,000.
* It is possible for re-arm time to be affected if the PCI bus is being heavily utilized by many devices such that the digitizer is deprived of bus bandwidth to transfer low bandwidth acquisition information. There is separate, limited onboard memory to queue up this information (whch contains timestamp data about when the records started, stopped and how much data was stored). For a single board case - this should peak at around 7MB/s for our fastest rearming digitizer triggered at its highest rate. If the system does get overloaded, the board stalls the start of the record to prevent loss of data. This should never happen in any reasonable scale system - an 8 slot chassis is clearly fine. However, if you are rearming many records as fast as possible, this factor will throttle your maximum waveform transfer bandwidth down accordingly.
