For the purposes of my reply you have to understand that I have never had the toolbox or any appropriate DAQ hardware in my hands. I can't answer questions about the best method to metaphorically file down the spark plugs to achieve the ultimate in performance.
I used to follow a bunch of the DAQ postings, and read specs and look at theoretical bandwidths. I have not done that in over a year, and I know for a fact that my long illness has affected my memory.
So with some educated but fuzzy "armchair quarterbacking", the answer to your question is:
Can you get close to 250 Ksamp/s with the USB-6211 with the DAQ Toolbox? NO WAY.
And LabView is not likely going to be able to achieve that for you either.
The maximum I remember hearing anyone reach with the DAQ Toolbox with the NI cards of that series, was about 60 Ksamp/s; and they said they worked directly with Mathworks to tune everything. Otherwise people were getting 4 Ksamp/s to 10 Ksamp/s with similar cards.
If you want to get maximum bandwidth out of an NI DAQ card, then don't use USB. And put the card into a data acquisition chassis that can buffer samples and timestamp them and transfer them to MATLAB in larger chunks.
USB is a shared serial bus that uses a master/slave polling architecture. The master keeps track of all the devices on the bus and sends each of them in turn a query as to whether they have anything to pass back. The response from the device is not the data, it is a share request, an indication of how much data is ready and what kind of data it is (because USB treats streaming data as higher priority than block-oriented devices since the block request can always be re-sent if need be.) In the case of small amounts of data, the single packet response from the device can include the data itself, but for anything past that, the response is just "No, nothing from me" or "Yes, I have N bytes of data of type T, or I want to reserve 400 ms to transfer time-sensitive data". The master polls all of the devices on the bus to find out what everyone wants to do. From there the master decides on a schedule. And then the master sends a command to the device to actually deliver the data, with the device immediately replying with the data; the device is entitled to exclusive use of the shared serial bus while it is doing so. Then the master sends a command to the next device on its schedule and receives data in return. Until all the devices have been serviced once (or have said they don't want anything.) After that, the master starts the cycle again, polling to see which device wants attention, deciding what order to handle the device requests and how much time they are allocated, and telling the devices one by one to go ahead.
This USB scheme has some nice advantages in a shared environment, but it farts smelly cabbage bubbles for low-latency fast-repeat situations even on unshared busses. Direct bus connections, and eSATA and eSATA over "Thunderbolt" (Apple: "Lightning") can do much better. USB with a high KSamp/s rate is like souping up the RPM of an engine without putting in a better transmission.
The best you can really do with USB is use it as an interface to a device that is collecting and buffering (and time-stamping) the data into larger buffer-fulls so that when your device gets its USB share, it can respond with a maximum length packet packed full of data, thus amortizing the protocol overhead over longer continuous data transfers. And better yet with USB is to go USB 3.0 has it has a faster bus rate, faster signaling, and larger packets so you can amortize the protocol even better. But you will definitely want to be using a data collection chassis for that, because the protocol overhead for sending a small number of bytes gets ugly, especially if the number of bytes is higher than what can be returned in as "immediate" response to a poll-for-work.
These factors are not MATLAB specific, which is why I doubt that LabView would be able to get you anywhere near 250 KSamp/s either in practice, not with the USB-6211 card and a direct connection.
If you have a poll-and-respond situation, where you need have a program send the device a command to send a data sample, situations where you have a virtual COM port over USB, then you run into a problem with the implementation of USB virtual serial devices. USB virtual serial devices are defined as being required to buffer data until a certain period of inactivity with no further requests to send, or until the packet is full. The protocol is not line-oriented: it will happily collect a number of lines before the packet fills up or the timeout occurs. And only then will the data be sent. This occurs on both sides. The USB protocol defines a PUSH mechanism: you can specifically tell the USB master to send the packet as soon as a USB bus slot is available. But MATLAB does not offer any mechanism to tell the master that. I suspect that LabView has more possibilities that way. if I recall the timeout correctly, the maximum virtual-serial packet rate you can get with USB 2.0 (with non-full packets that are not PUSH'd) is 4 Hz (a 250 ms timeout.) I could be wrong on that figure, but it certainly is not higher than 10 Hz.
USB 2.0 is not the right mechanism to use for short-packet short-latency high-repetition-rate data transfers. As far as I was able to determine back when I was reading about such matters, 250 KSamp/s is truly unachievable with USB 2.0, unless you have some sample buffering before transmission over USB.
