Hi Brian, On 5/30/2012 5:22 PM, Barrett, Brian W wrote:
Mohamad -
I can't speak for others. I can say that there was a general feeling from those who voted no or abstain that the need for a non-blocking file I/O collective, when split collectives are already unable to provide any asynchrony, is a problem for implementors.
I agree with you that an implementation is not easy for those routines.. But I don't see that it should be a reason for voting a ticket down, or worse saying that it should be postponed, because the implementation challenge will still be there for 3.1
The problems with file position and ordering is still a bit unsettling to some.
Is that something new for any of the file routines (blocking and non blocking)? The consistency semantics are defined as clear as any of the other file routines.
Also, I know that for myself, I haven't voiced objections in the last couple of meetings because my objections had been made previously and not well addressed, so I was going to vote no. This happens in any voting body.
It was poor scheduling that the last first vote occurred on a foreign trip. I tried very hard to get someone to speak up about each ticket ahead of time, as I can't speak for many of the tickets (and it would not be fair for me to give initial background on a ticket I was going to vote "no" for). This was obviously problematic for some tickets. The discussion on the ifile ticket largely covered the points I raised in the initial paragraph.
Admittedly I might have done something to try and get people to speak up about this ticket a couple of weeks before the meeting, but my problem with this, by looking at my slides for all the presentations I made for this ticket where I record all the straw votes, there were two straw votes at 2 separate meetings, a 17-0-1 and another similar straw votes on this ticket. The ticket that got a lot of objections (many from you) was the nonblocking file manipulation routines ticket, which was withdrawn. The only problem that was voiced for this ticket was the issue with shared file pointers. This was addressed at the last meeting, and everybody seemed content with the draft read. I don't want to sound stubborn here, but between the voting rules change, and the lack of feedback given from people for this ticket, I'm a bit frustrated. Mohamad
Unlike some of the other tickets that were voted down, the ifile ticket was one of two (FT being the other) that people were more receptive to seeing in MPI-3.1.
Brian
-- Brian W. Barrett Scalable System Software Group Sandia National Laboratories ________________________________________ From: [email protected] [[email protected]] on behalf of Mohamad Chaarawi [[email protected]] Sent: Wednesday, May 30, 2012 2:24 PM To: [email protected] Subject: [EXTERNAL] Re: [Mpi-forum] ticket 273
Hi Rich,
On 5/30/2012 3:03 PM, Richard Graham wrote:
Mohamad, Two items that I wrote down based on comments: - One view was expressed that adding a nonblocking interface, will not change the fact that implementation will still be blocking The implementation that UH provides builds on top of libnbc which implements the non-blocking collective communication operations.. They use non blocking point-to-point operations and asynchronous aio_read/aio_write functions. So what part of that is blocking?
btw, why was this concern not mentioned during the formal reading or on the I/O mailing list?
- The ticket was rushed, and not ready This ticket was going back and forth for a little less than a year.. I don't any reason why it is considered rushed.. Again most of the I/O chapter committee reviewed and approved it.. Other than final merging issues what was wrong with ticket? and again why were they not brought up till the Japan vote, where we were not there to address them?
Thanks, Mohamad
Rich
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mohamad Chaarawi Sent: Thursday, May 31, 2012 4:37 AM To: Main MPI Forum mailing list Subject: [Mpi-forum] ticket 273
Hi All,
I'm still trying to figure out why ticket 273 was voted down. At the last meeting, I would say there was a consensus that the non blocking collective I/O ticket (273) was ready to be voted in. Nobody expressed an objection after me removing the shared file pointer nbc routines and re-reading the draft. All the I/O chapter committee reviewed the draft and commented on the ticket that it looks good.
At the Japan meeting, we get 8 yes , 2 nos, and 6 abstains, which under the new rules marks the ticket as failed. None from our organization could attend the meeting to really understand what the 2 no votes were for, and why 6 organizations abstained. If the abstains are because people don't care or don't understand what is being voted on or missed the vote (which are the reasons why I vote abstain), then the new voting rule doesn't really make sense. If the abstains where for something else, then the votes should be NO. So could someone mention why this was voted down?
Thanks, Mohamad
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum