Multifunction DAQ
DAQmxWriteDigitalU32 strange behavior / slow when overwriting entire buffer in regen mode - DMA completion wait?
After much spelunking and grinding of teeth, we've figured out why the behavior is what you see. Here is what you're doing at a high level:
The black outline is the virtual buffer that DAQmx owns. Since we're doing a continuous task, conceptually this buffer can be looped over indefinitely. The first thing to notice is that hardware is consuming data and is at some random point in the buffer. I've indicated that with the purple arrow. DAQmx doesn't want to update the buffer out from underneath hardware as its consuming because that would always cause a glitch. So we do the best thing we can do, and move the write position past the hardware position.
Now, remember, this the black outline is the virtual concept of the buffer. Physically, the buffer is only a single chunk of memory that we loop around. So in this new picture, we're still updating the same position, but now we're going to wait so that we don't overwrite hardware as it consumes.
Now, the next thing to know is that we never write to the buffer more than half the buffer size at at time. So, to update the full buffer, we actually do two writes.
The green section is now the first write we will do, and the red section is the second write we will do.
Now, to do the first write, we still need to make sure we don't overwrite hardware. There we want to make sure it gets done consuming that portion of the buffer. So now we wait on hardware.
Ok, so once the hardware has consumed up to the dotted line, we can write the green portion. Lets assume we've done that. Now we are in this case.
Now, just like before, we don't want to overwrite what hardware is doing. So we have to wait for it AGAIN to write the red portion until the hardware has consumed the data we are going to overwrite.
Once we've waited, we can write the last half of the data.
Finally, considering this is just a visual representation of a buffer being regenerated from, this is now the final state.
That was long-winded. The bottom line is that there were two points in that sequence where we waited on hardware. One was for hardware to get halfway through the buffer. For a buffer of 4096 samples and an update rate of 2 MS/s, that should be between 0-1.024 ms. The second wait was for it to get all the way through the buffer starting from halfway. That should take 1.024 ms more. So the total is 1.024-2.048 ms which is what you're seeing when you write the full buffer. When you write half a buffer you will get random amounts of times from 0-1.024 ms which is also what you're seeing. On top of this there is software latencies which sometimes cause us to get in weird situations where stuff will take a little longer because we hit an edge case where we were perfectly lined up with hardware, but by the time the second half of the buffer went to be written hardware happened to pass us so we wait again!
To illustrate the 0-1ms, for example, when I do a 4096 sample buffer and a 2048 sample write I see these write times (with a very low resolution timer unfortunately):
As you can see, it often takes 0 ms (<1) and has some interesting aliasing where is starts taking 2 ms (<3 but >1) for a while.
Unfortunately, this whole mess the driver undertakes is in an effort to prevent glitching. Despite this, we glitch anyways and generate that warning I'm sure you're seeing, 200015. You don't care about the glitching and really want a way of saying, "look just overwrite immediately, I don't care if the hardware glitches", which doesn't currently exist.
All of this is to say, I'm not really sure how to make the write take less time. We need some brainstorming on that, I think.
