BUFE Bit

keiji_katata at post.pioneer.co.jp keiji_katata at post.pioneer.co.jp
Mon Feb 12 18:40:23 PST 2001


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



Hello again,

What document says "SYNCHRONIZE_CACHE command shall be issued at the end of
TAO/SAO/DAO"? If device did not receive SYNCHRONIZE_CACHE command, device
shall generate CHECK CONDITION STATUS? I do not see such a document. In the
case of RAW mode of CD, how to detect the sector mode by the device? Bill
and you did not show clear function and internal operation of device. What
is automatic behavior? According to your idea, device shall perform Burn
Proof for Block type 8-13. So end users suddenly get buffer under run error
when audio track recording is started. I do not think this is good idea.

Anyway, we can expand BUFE to CD recording to control Burn Proof by host.
Bill and your idea can be adopted when BUFE is set to 0. I think only issue
is what behavior shall be taken by device to perform safe Burn Proof with
any existing writing software or software of Microsoft. I think everyone
really want to know the safe Burn Proof behavior when BUFE is set to 0.

We must talk technical idea for our end users. Drive manufactures already
start shipping of Burn Proof products. If you know problem potentially, let
us know your possible problem. We can discuss it.

Best regards,

Keiji Katata
PIONEER CORP.




reply to mtfuji5 at avc-pioneer.com

to:   mtfuji5 at avc-pioneer.com
cc:   "Emily Hill" <emhill at microsoft.com>, mmc at dt.wdc.com, T10 at t10.org
      (bcc: Keiji Katata/Pioneer)
subject:  RE: BUFE Bit


Katata-san,

Perhaps we are discussing two different write modes?  It is my
understanding that both Track At Once and Disk At Once recording require
a SYNCHRONIZE_CACHE command to be sent to the device to finish the
writing process without an error being generated.

However, we have not the large hardware knowledge you possess.  Thank
you for bringing the compatibility issue with some audio players to our
attention. If audio players (not CD-ROMs) sometimes cannot handle clock
slippage, perhaps ammending the MMC proposal to enable BUFE only for
certain data block types would be more appopriate.  I would suggest
block types 8-13 (they are all data, and must be scrambled before placed
on the media) could benefit from this ability without impacting audio
tracks and audio players.

Resolution of this issue is important to both our companies, to provide
the consumer the best results.  Your quick response to this issue is
greatly appreciated.

Sincerely,



Henry Gabryjelski


-----Original Message-----
From: keiji_katata at post.pioneer.co.jp
[mailto:keiji_katata at post.pioneer.co.jp]
Sent: Sunday, February 11, 2001 10:27 PM
To: mtfuji5 at avc-pioneer.com
Cc: mtfuji5 at avc-pioneer.com; mmc at dt.wdc.com; T10 at t10.org
Subject: RE: BUFE Bit





Hello Henry,

You may forget the reason why 32K linking loss is prepared. If you
select
32K linking loss or Disc at Once recording mode with BUFE=0, any user
data
sectors do not have linking point. There are no guarantee that any
player/drive can read linking point. The linking point looks like black
dot, but it is deferent very much. Black dot never cause clock slippage
(
discrepancy before and after). But linking shall cause clock slippage
and
cause data bit slip. We know some decoder can not recover from this
situation. The result is unrecovered error.
In the case of CD audio, delay of recovery causes audio pop noise. If
data
transfer rate is slow, drive may make a lot of 0 link and error
correction
ability is decreased.

The other hand, drive can not see the end of write data transfer from
host.
When BUF works, drive shall wait next write data even if buffer becomes
empty. Drive can not perform linking. So almost all command shall be
terminated with CHECK CONDITION, OPERATION IN PROGRESS. This means I'm
writing.
When can drive perform linking at buffer empty? After 1 second waiting?
2
seconds? 3 seconds? When I'm downloading contents from Internet, waiting
time 1 second is long enough?

We provide BUFE bit to keep compatibility with legacy environment. We
provide BUF (Burn Proof) for user convenience. When BUFE is set to 0, it
is
possible to make intelligent implementation in drive. But it should be
vender unique behavior. It may cause same problem as drive designed
before
MMC1.

Anyway, Burn Proof can be carried out even if BUFE=0. It is vender
specific
fuction. Or do you make good proposal in MMC4?

Best regards,

Keiji Katata
PIONEER CORP.




reply to mtfuji5 at avc-pioneer.com

to:   mtfuji5 at avc-pioneer.com
cc:   mmc at dt.wdc.com, T10 at t10.org (bcc: Keiji Katata/Pioneer)
subject:  RE: BUFE Bit


Katata-san,

Requiring the host to set the BUFE bit in the mode page continues the
problematic use of mode pages.  I agree with Bill that the default
setting should be automatically enabled.  If this is not the case, then
the host will not get the benefits of this functionality.  Hosts should
*never* depend upon error conditions for proper completion of commands,
such as completion of writes -- this is a very poor design.  The MMC3
document supports an error-free model of working with the device.
Should you desire the host to know this information, please suggest a
method for it to retrieve such information using the GET_CONFIGURATION
command.

sincerely,
.




-----Original Message-----
From: keiji_katata at post.pioneer.co.jp
[mailto:keiji_katata at post.pioneer.co.jp]
Sent: Wednesday, February 07, 2001 9:19 PM
To: mtfuji5 at avc-pioneer.com
Cc: mmc at dt.wdc.com; T10 at t10.org; mtfuji5 at avc-pioneer.com
Subject: Re: BUFE Bit





Hello Bill,

I can not understand what you want.

You already know the problem that after write command issued, host need
to
send synchronized cache command to execute complete write on disc when
BUF
is enabled. I think we need not to talk about the reason because it is
drive implementation issue. Anyway, Host shall know the BUFE settiong.

And what is the function that shall be handled automatically by the
device?
What is your automatic behavior? It shall deferent with us. You want to
go
back before MMC1 period? If you have very good automatic behavior, you
must
make your proposal for the document. If you need not to change document,
you must not change our implementation. You can go your way.

Without any actual proposal and explanation by document, you must not
change the document only for your convenience.

Keiji Katata
PIONEER CORP.




reply to mtfuji5 at avc-pioneer.com

to:   mmc at dt.wdc.com, T10 at t10.org, mtfuji5 at avc-pioneer.com
cc:    (bcc: Keiji Katata/Pioneer)
subject:  BUFE Bit


MMC3 subject:
Recently, the BUFE bit (WRITE PARAMETERS MODE PAGE) has been extended to
include CD-R/RW.  There has been some concern raised by host software
people
that this may not work well.

In fact, we do not understand why this has value in the case of
DVD-R/RW.
Specifically, providing the host with the ability to switch this feature
on
and off may only provide the host with additional complexity and no real
value.

The value of BUFE as it applies to DVD is a subject for RMC/MMC4,
however,
let us first consider changes to CD.  Due to the widespread use of
CD-R/RW,
we should serve the existing platforms by not changing anything.  When a
device has the lossless linking capability with CD-R/RW, the control of
the
feature is best left with the drive to apply during long streamed
writing.

It is important to have this function handled automatically by the
device.
That insures the highest level of compatibility.  So, I wish to remove
the
use of BUFE for CD in MMC3.

Bill McFerrin















*
* 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