Action Items on Fuji meeting December 15, 2003

Hiromichi Oribe Oribe at iomega.com
Wed Jan 7 16:57:49 PST 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Hiromichi Oribe" <Oribe at iomega.com>
*
Henry-san,

>Existing applications exist which understand the device busy event as
>specified by Katata-san's proposed changes.  This was due to two
>interpretations of the previous specifications, and the dual
>interpretations apply to both software and hardware vendors.
>....
>Changing the time unit will cause invalid information to be reported by
>these existing applications and OS, potentially causing incorrect
behavior
>by the software.

Thank you for your detailed information and I realized I was missing
some things.  I now understand that some existing OS and application
that are already using Time field to obtain progress indication during
immediate command operation.

This makes me believe we have to go with your option (A).

Best regards,

Hiromichi Oribe
oribe at iomega.com
1821 West Iomega Way, Roy, Utah 84067
tel 801-332-5360
fax 801-332-4667

-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Henry Gabryjelski
Sent: Wednesday, January 07, 2004 3:39 PM
To: mtfuji5 at avc-pioneer.com
Cc: T10 at t10.org
Subject: RE: Action Items on Fuji meeting December 15, 2003

Oribe-san,

You wrote below:

> I'm not quite sure why you are concerned about legacy...The
> Proposal includes adding a new bit in Core Feature Descriptor
> (DVEvent bit) to say if the device supports new device busy
> reporting scheme.  If DVEvent bit (or some other bit) is set,
> use 1 second for time unit otherwise use 100ms can solve the
> issue.

Please excuse me for not being clear, and allow me the opportunity to
provide
additional information on the area which may be of concern.  Existing
applications exist which understand the device busy event as specified
by
Katata-san's proposed changes.  This was due to two interpretations of
the
previous specifications, and the dual interpretations apply to both
software and
hardware vendors.

The inclusion of the new bit to make clear the use of the device busy
event does
not 100% solve any problems, although it provides future OS and
applications the
ability to know for sure that a device is using it in the proposed
manner.
However, some existing applications and OS are already interpreting the
Device
Busy event as the proposal indicates, where the unit of time is 100ms.
Changing
the time unit will cause invalid information to be reported by these
existing
applications and OS, potentially causing incorrect behavior by the
software.

Historically, even though software can be updated, the market has shown
that
there will always be some segment which does not update the software to
understand new drive behavior.  This segment of the market is of concern
to many
hardware manufacturers and many software companies also.  Therefore,
many
decisions in the Mt. Fuji/MMC group require significant analysis of
existing
software (and sometimes embedded) device behavior to guide a decision.

In this case, modifying the time unit will result in some OS reporting
invalid
time-to-ready.  Because this data is broadcast to all listeners on at
least one
OS, and some segments will not have updated OS software, the impact to
other
added software cannot be accurately determined.  So, I hope this
explains why
adding the DBEvent bit, while useful for new host software, does not
automatically allow significantly behavior deviation.

So, I have attempted to provide this information to the group, to hear
other
views on this issue, to hear of other possible solutions, and to find a
consensus on the appropriate final solution.  If the agreement is that
changing
the time unit is an acceptable risk, then further discussion will need
to be
done in that area to determine the best time unit to minimize risk to
existing
(legacy) environments.

Please let me know if I have made more area unclear, so that I can again
have
the opportunity to clarify my poor descriptions.

.
 

-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of Hiromichi Oribe
Sent: Wednesday, January 07, 2004 11:38 AM
To: mtfuji5 at avc-pioneer.com
Cc: T10 at t10.org
Subject: RE: Action Items on Fuji meeting December 15, 2003

Henry-san,

Thank you for your comments.

>1.8 hours to format.  What should the upper range of time to report be?
Is
>3.8 hours enough?  9 hours?  Is 18 hours sufficient for all future
devices?

Longest format time (typical case) for our device is currently 3.5
hours.  I'm not sure if 18 hours is long enough but longer the better in
this case to cover all the future devices except changing time unit to
too big (i.e. 10 seconds) can be a problem because some immediate
operation like sync cache take way less than 10 seconds and it won't be
useful.

>(A) Perhaps instead of redefining the meaning of the time unit, it
would be
>acceptable to redefine the value of '65535' units to mean "more than or
>equal to (65535*time unit) time remaining".  Then, if the time
remaining is
>too large,

(A) is an option if we have to use 100ms time unit.

>(B) If a smaller maximum time (3.8 hours, 9 hours) is sufficient, then
> report the time unit in 200ms or 500ms units to minimize the error
> encountered by legacy solutions.

I'm not quite sure why you are concerned about legacy...The proposal
includes adding a new bit in Core Feature Descriptor (DVEvent bit) to
say if the device supports new device busy reporting scheme.  If DVEvent
bit (or some other bit) is set, use 1 second for time unit otherwise use
100ms can solve the issue.

>200ms or 500ms units

I think 1 second time unit makes some sense because this is already used
for Group 1 and 2 timeouts.

Best regards,

Hiromichi Oribe
oribe at iomega.com
1821 West Iomega Way, Roy, Utah 84067
tel 801-332-5360
fax 801-332-4667

-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Henry Gabryjelski
Sent: Wednesday, January 07, 2004 11:20 AM
To: mtfuji5 at avc-pioneer.com
Cc: T10 at t10.org
Subject: RE: Action Items on Fuji meeting December 15, 2003


Oribe-san,

This is an interesting problem.  If you look at Katata-san's documents,
you can
see that some manufacturers have already implemented the busy event in
both
ways.  So, the time field is currently used as 100ms by some drives.
I understand your concern that there may be devices which can take
longer than
1.8 hours to format.  What should the upper range of time to report be?
Is 3.8
hours enough?  9 hours?  Is 18 hours sufficient for all future devices?

I see three options:

(A) Perhaps instead of redefining the meaning of the time unit, it would
be
acceptable to redefine the value of '65535' units to mean "more than or
equal to
(65535*time unit) time remaining".  Then, if the time remaining is too
large,
the host can still know it will be a very long time.  I think this would
not
cause any significant host problems; I am not aware of any host which
allows
more than a few minutes to pass between updates of the device busy
event, even
if such a large value is reported.  I will be looking to see if
reporting the
time in seconds will cause any issues, as the legacy solutions will be
seeing
times which are "too small".

Pros: No legacy compatibility issues.

Cons: Very large time-to-ready is not accurately available.

(B) If a smaller maximum time (3.8 hours, 9 hours) is sufficient, then
report
the time unit in 200ms or 500ms units to minimize the error encountered
by
legacy solutions.

Pros: Allows larger time-to-ready to be reported.

Cons:  Some current OS are using the time field already as defined in
Katata-san's document.  Also, some OS are broadcasting this data to
any/all
user-mode clients who are listening for these events.  So, changing the
time
unit may cause application compatibility issues until the OS is updated
to
account for new time unit field.

I am open to opinions on which of these options would be preferred.
Please
respond to the reflectors with any comments.

.
 

-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of Hiromichi Oribe
Sent: Tuesday, January 06, 2004 6:05 PM
To: mtfuji5 at avc-pioneer.com
Cc: T10 at t10.org
Subject: RE: Action Items on Fuji meeting December 15, 2003

Hi Katata-san,

I reviewed the DVEvent proposal and I have one comment.

Since you are redefining Busy Event, do you also want to change units
for Time field from 100ms to 1 second?  Is there any reason why you
don't want to do this?

65535 * 100ms = 1.8 hours
65535 * 1 second = 18 hours

1.8 hours may not be long enough to report format in progress.

Best regards,

Hiromichi Oribe
oribe at iomega.com
1821 West Iomega Way, Roy, Utah 84067
tel 801-332-5360
fax 801-332-4667



-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
keiji_katata at post.pioneer.co.jp
Sent: Monday, January 05, 2004 2:10 AM
To: mtfuji5 at avc-pioneer.com
Cc: T10 at t10.org; twg3 at ml.cds21solutions.org
Subject: Action Items on Fuji meeting December 15, 2003

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,

I put following files in <ftp.avc-pioneer.com/Mtfuji5/Proposal/Dec03>.
They
are proposal files.

Device Busy Event change:
      prop_core.pdf
      prop_tout.pdf
      prop_DBE.pdf

Operational Change Event change:
      prop_morph.pdf
      prop_OPCE.pdf

Write Speed change:
      prop_rts.pdf
      prop_getp.pdf
      prop_WS3.pdf      (revise proposal)
      prop_WS4.pdf      (new proposal)

I think Write Speed (format 3h) can be revised to meet current
implementation. New Write Speed (format 4h) is meaningless. This can not
solve the current problem.
Software people, please send your preference to reflector or me.

Best regards,

Keiji Katata
PIONEER CORP.



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list