BUFE Bit

keiji_katata at post.pioneer.co.jp keiji_katata at post.pioneer.co.jp
Sun Feb 11 22:27:17 PST 2001


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



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