NI USB - 6211 takes around 1 min to perform Analog write at certain time intervals.

[RobinGeorgeKoshy]

1. On Running the above script the following error is observed on NI USB - 6211.

DAQmxErrorSamplesCanNotYetBeWritten (-200292)
Some or all of the samples to write could not be written to the buffer yet. More space will free up as samples currently in the buffer are generated.
To wait for more space to become available, use a longer write timeout. To make the space available sooner, increase the sample rate.

2. It is NOT observed on the devices below.
1. NI PCIe - 6363 (X series)
2. NI PCI - 6251 (M series)

Additionally,
3. On Setting DAQmxWriteAnalogF64 to DAQmx_Val_WaitInfinitely, and timing it.
The following is the observation [Refer offset_duration.csv]
Offset - is the no. of samples written into the buffer. [This is derived from the loop counter --> for (offset = 0; offset < TOTAL_SAMPLES; offset += BLOCK_SIZE)]
Duration - is the time taken to execute DAQmxWriteAnalogF64 [Derived from NI IO Trace].

So, at offsets of 8184, 24564.. it took 61s, 63s and so on..

Eg: The 8184 th sample takes 61 sec to complete
Refer: Trace entry(Number) 9706 in 6211InfiniteTimeout_9000samples.nitrace

Attached:
1. Buffer_Timeout.nitrace - IO Trace for the above code.
2. test.c -- Reproduction code
3. offset_duration.csv -- Intervals/Offsets where the write takes 1 min.
4. 6211InfiniteTimeout_9000samples.nitrace - IO Trace with Infinite Timeout

[Kevin_Price]

I certainly don't have a complete answer, and I'm a LabVIEW programmer who knows DAQmx capabilities and not the C syntax.   But I think that some of the following points will be of relevance for figuring this out:

1. USB-connected devices will often be subject to limitations when compared to desktop-bus-connected devices (PCIe, PCI).  Latency and bandwidth are almost always lower performance than their desktop counterparts.  Occasionally there are other quirks I've read about here, sometimes related to data transfer block sizes for the USB streaming driver.  (This is separate from the "blocks" of data in your code.)
2. The size of your USB-6211's onboard FIFO is 8191 samples.   At your sample rate of 256 samp/sec, that represents 30 seconds worth of data.  The 60+ second delay you see is pretty much double that, which isn't really an explanation but it *does* seem suspicious to me.  
3. The offsets where the delays happen appear to be odd multiples of the FIFO size.  1x and 3x are listed in the message, the other odd multiples show up in the csv attachment.  Frankly, I can't think of a good reason for seeing all the odd multiples and none of the even ones, but again the pattern seems suspicious.
4. Your variable buffer[] is sized for BUFFER_SIZE (100008) but after starting the task, you're calculating a pointer offset into that buffer as large as TOTAL_SAMPLES (460800).  Trouble awaits, though this is likely not related to the problem you've described so far.

-Kevin P