> > Not to muddy the point, but if there's enough ambiguity in the Standard
> > for people to ignore the progress rule, then I think (hope) there's enough
> > ambiguity for people to ignore the sender throttling issue too ;)
>
> I understand your position, and I used to agree until I was forced to
> change my mind by naive users :-)
Right. That's what I meant by:
"Most of the vendors aren't allowed to have this perspective....".
>
> Poorly written MPI codes won't likely segfault or deadlock because the
> progress rule was ignored. However, users will proudly tell you that you
> have a memory leak if you don't limit the size of the unexpected queue
> and their codes with no flow control blow up.
Yep. I don't lose money when I tell these people to go fix their code. I like
to think that I actually get paid to tell these people to go fix their code....
>
> You don't have to make it very efficient (per-sender credits
> definitively does not scale), but you need to have a way to stall/slow
> the sender when the unexpected queue gets too big. That's quite easy to
> do without affecting the common case.
Not on my network. I don't have the nice situation that the Standard refers
to where one producer is overwhelming the consumer. For a reasonable number
of endpoints and a known offending sender, it's pretty straightforward to
do a user-level credit-based flow control.
I'm looking at a network where the number of endpoints is large enough that
everybody can't have a credit to start with, and the "offender" isn't any
single process, but rather a combination of processes doing N-to-1 where N
is sufficiently large. I can't just tell one process to slow down. I have
to tell them all to slow down and do it quickly...
-Ron
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}