On May 25, 11:37 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
The critical issue is learning (from Rich) whether it is actually
necessary to poll the status register on each iteration.
Yes, that's been a brave assumption.
Although, given the bandwidth of the cards, it's not unreasonable.
However, Bill Garber just reminded me that the CF card may not be
*uniform* in its access time. In particular, it may *occasionally*
"take a vacation" to adjust its internal state, and only manifest that
to the outside world as going "busy" for a while.
Well, the copy loop we've been talking of optimising isn't an issue
with this, as these variations in time will occur between block reads.
It will always be necessary to wait until the card is 'ready' before
doing the block transfer.
In this way CF cards are no different to hard disk drives, which will
have non-uniform seek time between blocks, and may go awol for brief
periods of time to do thermal recalibrations - it's just another block
oriented device.
It does remain to be seen how much additional time is 'lost' in these
waits, as we've focussed only on block transfers *after* the transfer
has been ACK'd. The fact that even the existing 'slow' loop has better
bandwidth than anyone is getting means that there are other places
that need looking into, but those may or may not be improvable.
Part of the 'problem' here is that most modern hardware is going to do
a lot more multiblock IO, which mitigates the setup time issues.
Although most of the high-speed cards use small on-card caches to
facilitate fast transfers, and multiple single block reads should
still benefit from this, assuming they're sequential.