** This is the quasi-official and semi-temporary T13 email list server. **
Actually our guys (i.e. ECC experts) did an internal analysis a while back.
For the old transfer lengths (i.e. 256 sector, 128Kbyte, limitation) the CRC
is OK. Any CRC/ECC's effectiveness rolls off gradually, but within this
range our guys were OK with it.
I don't know of anyone who has done a similar analysis with the new, longer
transfer lengths. But as you point out, if you just keep the individual
bursts down to a reasonable size you'll be fine (CRC is on a burst basis,
not a command basis).
Jim
-----Original Message-----
From: Hale Landis [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 19, 2001 7:46 AM
To: T13
Cc: Stephane Cattaneo
Subject: [temp t13] Re: Device pause in UDMA ...
** This is the quasi-official and semi-temporary T13 email list server. **
On Thu, 19 Jul 2001 10:39:12 +0200, Stephane Cattaneo wrote:
>I am trying to make some UDMA transfer and when I try to make a writing
>transfer of more than 1 sector (2 sectors
>for example), using the DMA write command 0xCA, I have a device pause at
>the end of the first sector (DMARQ not asserted), and I would like to
>know why the device makes a pause.
For what ever reason it wants to but most likely due to buffer and
FIFO full/empty conditions and error correction conditions. A device
can pause the transfer or even terminate the current burst for any
reason it wants and at any point (that is "legal") during a DMA
command's data transfer. Do not be surprised to see Ultra DMA pause
or even burst terminations frequently during DMA command executions.
Do not be surprised if you see hundreds (even thousands) of DMA
bursts during the execution of a DMA command. And Ultra DMA pauses
can happen even more frequently than within DMA bursts. Nothing
unusual going on here.
>Is there a way to avoid device pause ?
None. I assume your host side might need to do the same thing now and
then due to problems moving data to/from the PCI bus.
Remember that Ultra DMA bursts should not be too large because at
some point (is it about 16K bytes?) the CRC becomes ineffective.
*** Hale Landis *** [EMAIL PROTECTED] ***
*** Niwot, CO USA *** www.ata-atapi.com ***
--
If you have any questions or wish to unsubscribe send a
message to Hale Landis, [EMAIL PROTECTED] To post to
this list server send your message to [EMAIL PROTECTED]
For questions concerning Thistle Grove Industries or TGI's
list services please send email to [EMAIL PROTECTED]
--
If you have any questions or wish to unsubscribe send a
message to Hale Landis, [EMAIL PROTECTED] To post to
this list server send your message to [EMAIL PROTECTED]
For questions concerning Thistle Grove Industries or TGI's
list services please send email to [EMAIL PROTECTED]
