RE: Streaming, batching, concurrent and alternating

Hi John,

> We cannot stress enough the importance of enforcing determinism
> in SCE-MI 2.0 for all use modes. Any solution which puts
> responsibility for determinism on the user or IP vendor level is
> unacceptable.

You are talking only about determinism on the hardware side, here,
as per your previous email, right?  I like this to be stressed as
I tend to view the whole system when I consider determinism, not
just the hardware side.  But I think you're saying that if we can
relieve the user from having to learn yet more guidelines (besides
the Cummings ones) such as sane clock control, then we'll be better
off.

> We disagree with the premise that non-deterministic
> streaming is required for performance.

Doesn't it depend on what you mean by `performance'?  It is somewhat
relative.  Are you saying that you disagree that non-deterministic
streaming can yield higher performance than deterministic streaming
in some scenarios?  Or are you saying that you disagree that
non-deterministic streaming is required to get *adequate* performance?

> This is the ability to accumulate transactions on one
> end of a channel at a different rate than which they
> might be read at the other end (at least this is
> what I understood from Shabtay's e-mails).
> 
> Although this was not part of the agreed upon goals,
> the Mentor proposal refers to this as "data shaping".
> A couple of scenarios were discussed in this thread.

I think there is an important difference between Shabtay's batching
concept and data shaping as described in the Mentor model.  The
difference has to do with the end-of-message handling.  I believe
Shabtay's batching works on multiple messages, i.e., multiple
end-of-message indications.  Doesn't data shaping only work on one
message at a time?  At least that is how I interpret Section 4.4.2.2
in your proposal where it says: `However, if /data shaping/ is 
involved, the infrastructure does not pass the eom flag until the
last element of size bytes_per_element is read by the receiver'.
Let me know if I misunderstood the handling of the eom flag.

Thanks,
Per

-- 
Per Bojsen                                Email: <bojsen@zaiqtech.com>
Zaiq Technologies, Inc.                   WWW:   http://www.zaiqtech.com
78 Dragon Ct.                             Tel:   781 721 8229
Woburn, MA 01801                          Fax:   781 932 7488