This message is from the T13 list server.
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
ATA Interface Firmware & T13 (ATA/ATAPI) Standards Representative
Seagate Technology - PSG
e-mail: [EMAIL PROTECTED]
s-mail: 389 Disc Drive; Longmont, CO 80503 USA
voice: 720-684-2120
fax : 720-684-2711
====================================================
----- Forwarded by James C Hatfield/Seagate on 09/08/2003 10:39 AM -----
|---------+---------------------------->
| | "Grimsrud, Knut |
| | S" |
| | <knut.s.grimsrud@|
| | intel.com> |
| | No Phone Info |
| | Available |
| | |
| | 09/08/2003 09:22 |
| | AM |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: <[EMAIL PROTECTED]>
|
| cc: <[EMAIL PROTECTED]>
|
| Subject: RE: [t13] HOLD 20 dword response time
|
>------------------------------------------------------------------------------------------------------------------------------|
The numbers not adding up to 20 is no big deal. The purpose of the
example accounting was to show that the number was not pulled out of the
air and that it was possible with reasonable design to meet it. The
accounting adds up to 18 for the example implementation cited and the
spec allows up to 20 to account for some variation in specifics of the
designs.
Knut
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, September 08, 2003 8:16 AM
To: Grimsrud, Knut S
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [t13] HOLD 20 dword response time
Right - it's not really an issue. Or at least it's not the issue. The
real question was that the numbers didn't add up to the stated 20... I
remember Scott describing how he got there... I'll send him a message
asking him to resurrect the thoughts...
Cheers,
Tony
|---------+---------------------------->
| | "Grimsrud, Knut |
| | S" |
| | <knut.s.grimsrud@|
| | intel.com> |
| | No Phone Info |
| | Available |
| | |
| | 09/08/2003 09:03 |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-----------------------------------------------------------------------|
|
|
| To: <[EMAIL PROTECTED]>
|
| cc: <[EMAIL PROTECTED]>
|
| Subject: RE: [t13] HOLD 20 dword response time
|
>-----------------------------------------------------------------------
-----------------------------------------------------------------------|
19 would also be a new requirement. Either way it's a new requirement of
which you have to look at which new requirement might be the most
conservative one.
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
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, September 08, 2003 7:59 AM
To: Grimsrud, Knut S
Cc: [EMAIL PROTECTED]
Subject: RE: [t13] HOLD 20 dword response time
Wouldn't 21 be a new requirement... Everyone has always been working
to
20...
|---------+---------------------------->
| | "Grimsrud, Knut |
| | S" |
| | <knut.s.grimsrud@|
| | intel.com> |
| | No Phone Info |
| | Available |
| | |
| | 09/08/2003 08:39 |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-----------------------------------------------------------------------|
|
|
| To: <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]>
|
| cc:
|
| 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
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 6:11 PM
To: Grimsrud, Knut S; [EMAIL PROTECTED]
Subject: [t13] HOLD 20 dword response time
----- Forwarded by James C Hatfield/Seagate on 09/05/2003 07:09 PM -----
|---------+---------------------------->
| | "Elliott, Robert |
| | (Server Storage)"|
| | <[EMAIL PROTECTED]> |
| | Sent by: |
| | [EMAIL PROTECTED]|
| | rg |
| | No Phone Info |
| | Available |
| | |
| | 09/05/2003 05:09 |
| | PM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: "John Masiewicz" <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> |
| cc:
|
| Subject: [t13] HOLD 20 dword response time
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
This message is from the T13 list server.
In 15.4.8.1 of ata7v3r3c, regarding HOLD usage by the frame receiver,
the frame receiver must accept 20 more dwords after sending HOLD and the
frame transmitter must send no more than 20 dwords after receiving HOLD.
Since wire delay is really not zero, a worst case transmitter (that
sends a full 20 dwords) could overrun a worst case receiver (that only
has room for 20 dwords) because HOLD really takes some amount of time to
make it from one end of the wire to the other.
I suggest the frame transmitter be required to cease within 19 dwords to
fix the issue. Keep the frame receiver expectation 20 dwords.
I doubt any currently shipping frame transmitters take this long to
respond to HOLD today, so this shouldn't cause any device to be
noncompliant.
I would delete this from the sample budget:
"A one meter cable contains less than one - half Dword and is therefore
rounded to 0."
--
Rob Elliott, [EMAIL PROTECTED]
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
