It's the FIFO that's limited to 10 MBytes/second, tops, and in bursts, since the USB channel can't keep up with that. For that reason, it was necessary for me to put a ,ulti-MB buffer on my hardware to capture the entire data burst, then transfer it over the USB at whatever rate the FIFO and USB could handle. It was deemed inadequate, so I had to come up with something that didn't use Windows. Unfortunately, USB support for DOS, which is inherently capable of managing the task adequately, so USB was out.

That's not always the case, but it does happen enough to be noticeable.

The data bandwidth at the FIFO remains at 10 MBps, however, though that, in most cases is plenty. For those instances where the FIFO is the bottleneck, as it is in the case to which I refer, a big FIFO memory is necessary. Fortunately, SDRAM is cheap. Irrespective of the USB bandwidth, the FIFO performance is the rate-determining step in this case. There are many tasks that can tolerate a slow FIFO. This just wasn't one of them.

Even if the USB can provide the very high rate it claims, since it's in occasional bursts, with no mechanism at all for predicting how occasional, i.e. how long between visits by the OS, I have to buffer the entire message. In some cases, that's a lot of data.

The new part may be capable of more bandwidth at the USB, but the 100 ns (50 ns nWE + 50 ns precharge) read/write cycle is still a bottleneck. The irregular behavior of the OS with respect to its USB peripherals is the real problem, though.

RE