usb disk write latency (windows)

Question

I am writing to USB disk from a lowest priority thread, using chunked buffer writing and still, from time to time the system in overall lags on this operation. If I disable writing to disk only, everything works fine. I can't use Windows file operations API calls, only C write. So I thought maybe there is a WinAPI function to turn on/off USB disk write caching which I could use in conjunction with FlushBuffers or similar alternatives? The number of drives for operations is undefined.

Ideally I would like to never be lagging using write call and the caching, if it will be performed transparently is ok too.

EDIT: would _O_SEQUENTIAL flag on write only operations be of any use here?

Answer 1

Try to reduce I/O priority for the thread. See this article: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686277(v=vs.85).aspx In particular use THREAD_MODE_BACKGROUND_BEGIN for your IO thread. Warning: this doesn't work in Windows XP

Answer 2

The thread priority won't affect the delay that happens in the process of writing the media, because it's done in the kernel mode by the file system/disk drivers that don't pay attention to the priority of the calling thread.

You might try to use "T" flag (_O_SHORTLIVED) and flush the buffers at the end of the operation, also try to decrease the buffer size.

Answer 3

There are different types of data transfer for USB, for data there are 3: 1.Bulk Transfer, 2.Isochronous Transfer, and 3.Interrupt Transfer.

1. Bulk Transfers Provides:

   Used to transfer large bursty data.
   Error detection via CRC, with guarantee of delivery.
   No guarantee of bandwidth or minimum latency.
   Stream Pipe - Unidirectional
   Full & high speed modes only.
   

   Bulk transfer is good for data that does not require delivery in a guaranteed amount of time The USB host controller gives a lower priority to bulk transfer than the other types of transfer.

2. Isochronous Transfers Provides:

   Guaranteed access to USB bandwidth.
   Bounded latency.
   Stream Pipe - Unidirectional
   Error detection via CRC, but no retry or guarantee of delivery.
   Full & high speed modes only.
   No data toggling.
   

   Isochronous transfers occur continuously and periodically. They typically contain time sensitive information, such as an audio or video stream. If there were a delay or retry of data in an audio stream, then you would expect some erratic audio containing glitches. The beat may no longer be in sync. However if a packet or frame was dropped every now and again, it is less likely to be noticed by the listener.

3. Interrupt Transfers Provides:

   Guaranteed Latency
   Stream Pipe - Unidirectional
   Error detection and next period retry.
   

   Interrupt transfers are typically non-periodic, small device "initiated" communication requiring bounded latency. An Interrupt request is queued by the device until the host polls the USB device asking for data.

From the above, it seems that you want a Guaranteed Latency, so you should use Isochronous mode. There are some libraries that you can use like libusb, or you can read more in msdn

Answer 4

To find out what is letting your system hang you first need to drill down to the Windows hang. What was Windows doing while you did experience the hang?

To find this out you can take a kernel dump. How to get and analyze a Kernel Dump read here.

Depending on the findings you get there you then need to decide if there is anything under your control you can do about. Since you are using a third party library to to the writing there is little you can do except to set the IO priority, thread priority on thread or process level. If the library you were given links against a specific CRT you could try to build your own customized version of it to e.g. flush after every write to prevent write combining by the OS to write only data in big chunks back to disc.

Edit1

Your best bet would be to flush the device after every write. This could force the OS to flush any pending data and write the current pending writes to disc without caching the writes up to certain amount.

The second best thing would be to simply wait after each write to give the OS the chance to write pending changes though small back to disc after a certain time interval.

If you are deeper into performance you should try out XPerf which has a nice GUI and shows you even the call stack where your process did hang. The Windows Team and many other teams at MS use this tool to troubleshoot hang experiences. The latest edition with many more features comes with the Windows 8 SDK. But beware that Xperf only works on OS > Vista.