Description of rounding rules for PPR transfer agreements

George Penokie gop at us.ibm.com
Thu Dec 20 09:15:08 PST 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* "George Penokie" <gop at us.ibm.com>
*

Thanks Rob. The changes you suggest work for me. Gerry, what about you?

Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880



"Elliott, Robert" <Robert.Elliott at COMPAQ.com>@t10.org on 12/20/2001
09:59:35 AM

Sent by:    owner-t10 at t10.org


To:    <t10 at t10.org>
cc:
Subject:    RE: Description of rounding rules for PPR transfer agreements



* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert" <Robert.Elliott at compaq.com>
*
I think the concepts that:
a) paced runs exactly at the negotiated transfer period, and
b) non-paced considers the negotiated transfer period as a maximum
are covered by these statements in 4.9 and 4.10:

    4.9 Clocking methods for data transfers
    ... Regardless of whether ST or DT transfers are enabled the
    negotiated transfer period sets the maximum rate at which
    the data is clocked at in megatransfers per second. ...

    4.10 Paced transfer on a SCSI bus
    ...
    During paced transfers the clock signal (i.e., REQ or ACK)
    transitions at the negotiated transfer period.  Data is
    qualified by the clock signal and the phase of the
    P1 signal (see 10.7.4.3).
    ...

In the examples in Figures 6 and 7, the "maximum" concept should be
included.
Current:
    Example: A negotiated transfer period of 25 ns equates to a
    transfer rate of 40 megatransfers per second.
Change to:
    Example: A negotiated transfer period of 25 ns equates to a
    maximum transfer rate of 40 megatransfers per second.

In Table 5, the descriptions for 09h and up could change to make this
clearer.
Current:
    Transfer period equals ...
Change to:
    Transfer period less than or equal to ...

(leaving 08h as "equals")

---
Rob Elliott, Compaq Server Storage
Robert.Elliott at compaq.com



> -----Original Message-----
> From: George Penokie [mailto:gop at us.ibm.com]
> Sent: Thursday, December 20, 2001 8:09 AM
> To: Gerry.Houlder at seagate.com
> Cc: t10 at t10.org
> Subject: Re: Description of rounding rules for PPR transfer agreements
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "George Penokie" <gop at us.ibm.com>
> *
>
> I believe the wording Gerry is referring to was in SPI-4 r6
> (see below). It
> is located just above table 63.
>
> From SPI-4 r6 section 16.3.12.1:
> 'The initiator sets its values according to the rules above
> to permit it to
> receive data successfully. If the target is able to receive data
> successfully with these values (or smaller periods or larger REQ/ACK
> offsets or both), it returns the same values in its PARALLEL PROTOCOL
> REQUEST message, except for the PCOMP_EN value. If it
> requires a larger
> period, a smaller REQ/ACK offset, or a smaller transfer width
> in order to
> receive data successfully, it substitutes values in its
> PARALLEL PROTOCOL
> REQUEST message as required, returning unchanged any value
> not required to
> be changed. If the TRANSFER PERIOD FACTOR contains a value
> greater than
> 08h, each SCSI device when transmitting data shall respect
> the negotiated
> limits set by the other's PARALLEL PROTOCOL REQUEST message, but it is
> permitted to transfer data with larger periods, smaller
> synchronous REQ/ACK
> offsets, or both. If the TRANSFER PERIOD FACTOR contains a
> value equal to
> 08h, each SCSI device when transmitting data shall transmit
> data at the
> negotiated transfer period but smaller synchronous REQ/ACK offsets are
> allowed. The completion of an exchange of PARALLEL PROTOCOL REQUEST
> messages implies an agreement as shown in table 63. If the
> target does not
> support the selected protocol option it shall clear as many bits as
> required to set the protocol option field to a legal value
> that it does
> support.'
>
> I have looked over r8 and can only find the statement below
> which does not
> contain several of the allowable characteristics of the
> transmitting port
> defined in r6. This information is important and should not have been
> dropped. If I missed it then someone needs to point to the location in
> SPI-4 where it is stated.
>
> From SPI-4 rev 8 section 4.12.2:
> 'Ports shall not set message fields to values they do not support. The
> originating port should set the fields in the originating negotiation
> message to the maximum values (e.g., fastest transfer period, largest
> REQ/ACK offset) it supports. If the responding port is able
> to support the
> requested values, it shall return the same values in the responding
> negotiation message. If the responding port requires different values
> (i.e., a subset of the originating port's request), it shall
> return those
> values in the responding negotiation message (e.g., if the
> originating port
> asks for a REQ/ACK offset of 32 and the responding port only
> supports a
> REQ/ACK offset of 16, then the responding port replies with
> an offset of
> 16).'
>
> Bye for now,
> George Penokie
>
> Dept 2C6  114-2 N212
> E-Mail:    gop at us.ibm.com
> Internal:  553-5208
> External: 507-253-5208   FAX: 507-253-2880
>
>
>
> Gerry.Houlder at seagate.com@t10.org on 12/17/2001 05:52:44 PM
>
> Sent by:    owner-t10 at t10.org
>
>
> To:    t10 at t10.org
> cc:
> Subject:    Description of rounding rules for PPR transfer agreements
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> I recall that SPI-4 used to contain rules for "rounding down"
> a proposed
> transfer agreement for PPR message. There were several cases
> (e.g., period
> factor is too small to be legal for ST, or IU was requested but not
> supported) that were mandated to return the default transfer agreement
> (aynchronous narrow) instead of a slightly slower "rounded
> down" speed. I
> can't seem to find these rules in SPI-4 rev. 8. Were these
> rules removed as
> part of Rob Elliott's remaking of the transfer agreement
> rules, or perhaps
> removed earlier, or perhaps I just am not looking in the right places?
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list