This message is from the T13 list server.


> "Grimsrud, Knut   S" <[EMAIL PROTECTED]>
> 09/08/2003 08:39 AM
> Subject:  RE: [t13] HOLD 20 dword response time     
> 
> I think that if an action is taken here (and I'm not positive one is
> strictly needed) that a more conservative approach would be for
> receivers to tolerate reception of 21 dwords rather than require
> transmitters to pinch off within 19. This more conservative approach
> would ensure that a T13 variant SATA solution would always work with a
> solution built to the SATA specs. If you go the proposed way you don't
> have such an assurance and a functional discrepancy gets introduced.
> 
>                          Knut

That could make existing SATA hosts and devices non-compliant with
ATA/ATAPI-7 - they might only be able to receive 20 dwords 
after sending HOLD.

I think it's safer to change the transmit rule to 19.  This shouldn't
make any existing designs non-compliant, since transmitters are not 
hitting that that number today.  ATA/ATAPI-7 would just be tightening
the spec for better interoperability.

For a standard, the sample budget could (and perhaps should) be
deleted entirely.  Just state the requirement.

>From another message on this thread:
> I personally feel that this is another one of those issues 
> that are not really issues. Like the OOB intervals overlapping 
> and one of them needing a "<" and the other needing a ">=".
> 
>                          Knut

I agree that was just a standards-writing issue.

This discrepency, however, could lead to a dword being lost if both 
sides interpreted the rule in their favor.

Note that, in case SATA ever tries to support external cables,
a 10 m cable at 3 Gbps has about an 8 dword round trip time (or
4 dwords for 1.5 Gbps).  You need to adopt numbers like 12/20 
or 20/28 for HOLD/HOLDA to work with cable delays of that 
magnitude.

If any other entity is in the path adding latency, it gets even
worse (that entity may have to participate in HOLD/HOLDA itself
on each side and buffer data on its own).

--
Rob Elliott, [EMAIL PROTECTED]
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott



Reply via email to