** This is the quasi-official and semi-temporary T13 email list server. **
Warning, long-winded reply below...
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Friday, September 21, 2001 2:44 PM
>To: [EMAIL PROTECTED]
>Subject: [temp t13] Re: way too quiet on this list!
>
>Mixing standard IT commands with AV Stream commands is
>unacceptable, as any timing guarantees offered by the AV
>commands may be invalidated by any standard IT command.
>
>My personal summary: Use AV STREAM command for IT and AV data
>and do not mix standard IT command with AV STREAM commands.
>
>The error reporting for streaming commands, of course, needs serious
>consideration,
Yes that portion is a SW nightmare. I need to define an architecture
that can accommodate <n> outstanding incomplete commands that must
be retried. Some of those commands must complete in order to complete
other commands. For instance, I may need to read a table to find a
free location to put the incoming MPEG data. Yes I can design a better
system to minimize those kind of dependancies, but in the general case
that is not 100% possible. Just not realistic in a low-cost consumer
device.
So one thought for at least a first step is to use AV stream commands
for the MPEG data and normal RDS/WDS commands for everything else, and
take my chances that I don't get paused. Statistics I have gathered
on drive retry performance and my system access patterns support this
approach. The purist may not want to take that risk, but I have schedule and
cost constraints and have to compromise. I know the committee recommends
not to mix like this, but I have to balance risks here.
Even using the AV Stream commands on MPEG data does not prevent all
AV anomalies. There are many places in an MPEG stream where even a
single bit error can cause undesirable and noticeable effects. So my
drive procurement spec will still include a maximum "error" rate on how
frequently a command can return with erroneous data.
>My personal opinion is that even though this is an optional feature set,
>now is a good time to standardise it.
Historically, T13 has documented implementations that are at least up
and running if not already shipping. Yes, the "secret society" approach
where it is developed in private until working then publicly published.
Although this is distasteful to those outside the process it does work.
I'm not active on the committee anymore, but if I were I would probably
want some evidence that implementations have validated the proposal, and
that usually means sponsorship by at least 1 drive vendor and 1 host vendor.
If you need it and are designing to it, you better go support it.
>A point that seems to have raised some debate is the AV Model and
>the performance tables. From a hosts' perspective this is only a nice to
have
>which may be sacrificed if it jepardizes the complete AV Feature Set.
>Key features of an AV Feature Set that cannot be sacrificed are guaranteed
>command completion times, and time sliced error handling.
I don't know if it is controversial, but it is IMO overly complex and of
quite limited value to a host. There is always that worst case where I have
2 starving buffers requiring access to opposite ends of the media, so I must
design for that condition. I agree it is the least essential feature of the
proposal.
>As a final point, I would like to confirm that the (CE) hosts are still
>serious
>about using an AV Feature Set. The reason that there has been reduced
>presence in the T13 commission was related plainly to the fact that the
>AV Feature Set provides an excellent technical solution that we can use
>under the condition that the implementation follows the spirit of the
>standard.
Agreed that it is a good technical solution and probably not much else
can be done to improve it. If you believe it is that important (I don't
disagree) then pick a drive vendor or 2 to work with implementing it,
get your product ready and get those press releases rolling. Come to the
committee meetings with your drive partners and lobby for ratification.
Matt Rooke
CacheVision Inc.
1990 Concourse Dr.
San Jose, CA 95131
(408)321-1800 (main)
(408)321-1834 (direct)
(408)321-1902 (fax)
[EMAIL PROTECTED]
http://www.cachevision.com
--
If you have any questions or wish to unsubscribe send a
message to Hale Landis, [EMAIL PROTECTED] To post to
this list server send your message to [EMAIL PROTECTED]
For questions concerning Thistle Grove Industries or TGI's
list services please send email to [EMAIL PROTECTED]
