Results of DRI-1.0 Formal Vote

From: DRI Forum chairs Ken Cain and Anthony Skjellum


The DRI-1.0 specification was ratified unanimously by all voting institutions on Wednesday September 25, 2002. The final DRI-1.0 document is located at this URL: http://www.data-re.org/documents/dri-report-09252002.pdf .

The voting institutions and representatives were:
A formal vote was taken based on the September 16 2002 version of the DRI document ( http://www.data-re.org/documents/dri-report-09162002.pdf ). The vote responses were collected by The MITRE Corporation representative Brian Sroka. He disseminated the results in the email shown below on September 22, 2002. The options available to the voting members were:
The preliminary result was 4 yes votes and 1 no vote; enough to pass by majority. However, all comments received with the formal votes were addressed to the satisfaction of all voting members in the final document. Members who initially voted yes reiterated their yes votes. Members that voted no changed their vote to a yes, making the result unanimous.

Mercury Computer Systems, Inc. provided a pdf formatted version of its response, available at this URL: http://www.data-re.org/documents/Mercury_DRI10_vote.pdf .

SKY Computers, Inc. initially voted "no (disapprove) with comments".  SKY provided a list of comments with its formal vote that if resolved would change its vote to "yes (approve) with comments". These were subsequently resolved to the satisfaction of all voting members, and SKY's vote changed as indicated. SKY provided a marked up copy of the September 16 2002 version of the DRI document containing its complete set of comments (available at this URL: http://www.data-re.org/documents/SKY_09162002_document_feedback.pdf ). SKY also contributed editorial feedback in hard-copy form with grammar corrections.


-----
Ken Cain (Mercury Computer Systems, Inc.)
Anthony Skjellum (MPI Software Technology, Inc.)



Preliminary DRI-1.0 Formal Vote Responses Disseminated by The MITRE Corporation

Contents modified for formatting only (uniform header used for formal votes with comments to show organization/representative)



Dear Group,

I apologize for the delay.  Here is a summary of the DRI 1.0 Spec votes:

Mercury Computer Systems Inc.                     yea with comments
MITRE Corporation                                           yea
MPI Software Technology Inc.                        yea
Sky Computers Inc.                                            nay, possible yea
with conditions
SPAWAR Systems Center, San Diego           yea with comments

Below find the comments attached. -Brian

###########################################################
Company: Mercury Computer Systems, Inc.
Representative: Jon Greene

Date: September 18, 2002
Formal Vote on DRI 1.0

With regard to DRI 1.0 as embodied in the document posted at:
 http://www.data-re.org/documents/dri-report-09162002.pdf

Mercury Computer Systems, Inc. votes yes (approve) with comments.

The comments (in document order) are as follows:

Title page:
We suggest that the Document Status” note be removed.

Page 9, line 33:
We suggest that the sentence beginning with “error_code” be replaced with a
reference to the DRI Return Code Index.

Page 16, lines 26 – 28:
From a mathematical standpoint, any mod value should allow the implementation to
create a partitioning in which one or more parts
contain 0 elements since 0 mod n = 0 where n is any integer.

We suggest that this be explicitly mentioned to avoid possible confusion.

Page 17, line 21:
Typo: “as” should be inserted between “accepts” and “the”.

Page 17, line 21:
Typo: should be a period at the end of the line.

Pages 21 and 22:
We think that the Sample Packed Layout Specification Tables would be more readable
if the GDO were specified in row-major order
such that dimension 0 is the number of columns (X), dimension 1 is the number of
rows (Y) and dimension 2 is the number of planes Z.

Page 24, lines 22 - 23:
We believe this sentence is a little misleading in that it seems to imply that if
the rel_align specification is a multiple of the data element
size then no extra space will ever be inserted into the memory buffer. This is not
true. We suggest that the wording be changed to make
it clear that the suggested relationship (multiple) minimizes the amount of extra
space that may need to be inserted to meet the rel_align
specification.

Page 43, line 29:
We suggest that the sentence be changed to say “… collective, and depends
on the completion of DRI_Reorg_create by the processes on the other
side ..."

Page 56, line 21:
Typo: replace “return” with “returns”.

Page 63, lines 41 – 44:
Page 73, lines 21 - 23:
We suggest that the description of firstdata_offset be changed to make it clear
that pad values as well as actual overlap values are
included in the definition of firstdata.

Page 75, line 23:
We suggest that “owned” replace “assigned” to be more consistent with an earlier
description.

Page 75, line 27:
Typo: replace “dimensions” with “dimension”.

Page 77, line 23:
We again suggest that “owned” replace “assigned” to be more consistent with an
earlier description.

Page 77, line 28:
Page 79, line 28:
Page 81, line 42:
Page 83, line 42:
Typo: replace “dimensions” with “dimension”.

Pages 115 - 122:
We suggest that either Annex C (STAP example) be removed altogether from the
document or rewritten to use the correct DRI API.
------------------------------

###########################################################
Company: SKY Computers, Inc..
Representative: Steve Paavola

Attached is my review of the DRI document. My vote is to DISAPPROVE,
but there are only a few items to correct which will change my vote to
APPROVE, beyond the editorial comments.

1) We need to clarify the behavior of DRI_Layout_create_aligned. In
particular, the implementation is required to allocate the buffer with
enough alignment so that the user's alignments will be satisfied.

2) I think there's still some clarification needed on the behavior of
the group_dims array. For example, it is stated that "it is possible
that the implementation will select more than one process along the
affected data dimensions". We need to state exactly when this should
happen, not that it's "possible".

I believe that even if the user specifies DRI_GROUPDIMS_NOPREFERENCE or
DRI_GROUPDIMS_ALLNOPREFERENCE, the implementation must calculate the
group_dims array. Are there restrictions on the resulting array, just
as if the user filled it in? If so, there are potential restrictions on
the size of the group.

Steve

###########################################################
Organization: SPAWAR Systems Center, San Diego
Representative: Dennis Cottel

The DRI 1.0 specification is approved with the following comments:

page viii, lines 22 and 28: When referring to my organization, both citations
should read "SPAWAR Systems Center, San Diego".
"Systems" is plural, and because there are several systems centers, we need the
"San Diego" appellation.

viii/32: DARPA also provided support directly to SPAWAR Systems Center, San Diego
on this contract, and it should be so noted.

26/31: There is a missing opening parentheses before "group_dims[i]".

64/25: There is a missing period after the closing parentheses.

82/18 and 84/18:  This sentence appears in the Usage Restriction sections in these
two locations, but as the last sentence of the
Description section for all the other Blockinfo accessors.  The placement should
be consistent