Windows has a funny way of putting certain things ahead of others. Synchonicity is normally maintained under Windows in short bursts, but if you have a long process, e.g. a byte that has to be monitored and recorded at regular intervals, you have to provide a FIFO for it that's deep enough to get around the several seconds of "jitter" that Windows' prioritization imposes.

This showed up recently in an implementation using a USB-FIFO (FT-245M ?)setup. I was forced to put a large (64 MB) DRAM buffer memory between the synchronous hardware and the fifo because the FIFO depth was inadequate to "keep up" with the hardware, thanks to the occasional 3-4 second pause in Windows' processing of this link.

Now, I chose 64 MB not because every transfer is 64 MB, but because (a) I had supply of old SIMMs that served the purpose, and (b) I didn't want to revisit the problem due to inadequate buffer depth. I've never measured the depth of memory that's actually used, but I have observed multi-second lack of service from Windows. I've even seen circumstances wherein it fails to process keystrokes for upward of 5 minutes, while doing things unrelated to any active user task.

RE