Action Items on Fuji meeting December 15, 2003

Hiromichi Oribe Oribe at iomega.com
Wed Jan 7 11:38:00 PST 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Hiromichi Oribe" <Oribe at iomega.com>
*
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