[comp.periphs.scsi] SLOW WRITE ON OPTICAL ERASABLES

bill@camco.Celestial.COM (Bill Campbell) (06/14/91)

I'm in the process of evaluating erasable optical drives.  The
first drive I've installed is a Ricoh RO-5030E2, and I'm
surprised at how slow it is writing.  I ran a short tar job
to compare speeds with ctar's final report.

	ctar -Cvf /mnt/tarfile /bin	# 0.5MB/Min, optical
	ctar -Cvf /tmp/tarfile /bin # 3.1MB/Min, CDC Wren 675MB hd
	ctar -Cvf /dev/rct0 /bin	# 4.1MB/Min, Archive 150MB SCSI tape
	ctar -Cvf /dev/null /bin	# 26.1MB/Min, Maximum possible

Is this typical of erasable write speeds?  I expected them to be
slow, but not this slow!  Even removing a file from a directory
seems to take a long time while it updates the directory entry.

Bill
-- 
INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
             uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591

src@scuzzy.in-berlin.de (Heiko Blume) (06/16/91)

bill@camco.Celestial.COM (Bill Campbell) writes:
>I'm in the process of evaluating erasable optical drives.  The
>first drive I've installed is a Ricoh RO-5030E2, and I'm
>surprised at how slow it is writing. 

[benchmark]

>Is this typical of erasable write speeds?  I expected them to be
>slow, but not this slow!  Even removing a file from a directory
>seems to take a long time while it updates the directory entry.

magneto-optical recording has a problem: before writing data to
a spot that spot must first be erased. that means if you want
to write a block, it takes at least one full revolution + 1 block
of the disk. on average 1.5 revolutions are needed, which causes
the slow writing you experienced.

the 'solution' is to use a different method like phase-change
recording. for details see BYTE November 1990, page 289.
-- 
   Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!]
                  public UNIX source archive [HST V.42bis]:
        scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
                     uucp scuzzy!/src/README /your/home

caserta@athena.mit.edu (Francesco Caserta) (06/16/91)

You may want to look into the new all-optical drives, rather than MO. I'm
in the market for an optical drive for a Sun IPC and I've done some search.

All-optical drives use (Panasonic's) phase-change technology and don't use
magnets. Instead, a laser converts a spot on the medium to either an
amorphous state or a crystalline state. In the past, cyclability of
phase-change technology has lagged behind MO systems. However, phase-change
systems today offer cyclability rates equal to MO systems.

On Workstation News (June 91) there are the Benchmark Test Results between
Panasonic LF 7010 and Sony NWP-539. Sometime, these all-optical drives are
also called Multifuction Optical Drives, because they can function also as
WORM drives. Computer Upgrade Corporation markets a Pioneer-based,the 
Omnistor, with improved performance derived from use of a 250K RAM. If the
manufacturer's perfomance claims are true, this machine performs faster than
any Sony-based erasable optical, yet costs only $4195.

An all-optical drive that I know a little better is the `Duette' sold by
Maximum Storage (719) 531-6888. It's a 1GByte drive, supporting also WORM,
which costs $4995 for the Sparcstation (MAXSYS software included). The
rewriteable media cost $225 from Maximum. As it's expected from an
all-optical drive, the Duette is also quite small.

If anyone is using these new all-optical drives, we would be happy to
hear their experience. 

Thanks,

Francesco Caserta

martelli@cadlab.sublink.ORG (Alex Martelli) (06/18/91)

bill@camco.Celestial.COM (Bill Campbell) writes:
:I'm in the process of evaluating erasable optical drives.  The
	...
:	ctar -Cvf /mnt/tarfile /bin	# 0.5MB/Min, optical
	...
:Is this typical of erasable write speeds?  I expected them to be

We regularly archive expired news to a magneto-optical Maxtor drive,
with a "cpio -p" from the HP/UX box which runs our news to an
NFS-mounted erasable driven by a Sparcstation 1, at night (neither
machine is doing anything else, nor is there any other load on the
Ethernet).  We get LESS than 20 megabytes/hour (I have not analyzed
the details, but magnetic-disk to magnetic-disk "cpio -p"'s go SO
much faster that I feel certain that the drive, and possibly its
device-driver, are to be blamed for this "speed").
-- 
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; 
Fax: ++39 (51) 366964 (work only), Fidonet: 332/407.314 (home only).

pja@ralph.lafayette.la.us (Pete Alleman) (06/22/91)

>bill@camco.Celestial.COM (Bill Campbell) writes:
>	ctar -Cvf /mnt/tarfile /bin	# 0.5MB/Min, optical
>Is this typical of erasable write speeds?  I expected them to be

We use HP magneto-optical drives for logging real-time data.
The standard write runs about 300KB/sec with large block sizes
(400KB or so).  My application must sustain 350KB/sec, so
we have to pre-erase the disks and tell the drive not to
erase before each write.  The drive can sustain somewhere around
600KB/sec in this mode.

These drives have two limitations that can make them very slow.
They turn at 2400 rpm  and require two revelutions for each write,
and they have a VERY slow seek.  Try running tar to the raw device
with blocking set to 400KB.

-- 
Pete Alleman
	pja@ralph.lafayette.la.us

sdm7g@Virginia.EDU (Steven D. Majewski) (06/25/91)

In article <1991Jun15.173019.27914@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de
(Heiko Blume) writes:
>bill@camco.Celestial.COM (Bill Campbell) writes:
>>I'm in the process of evaluating erasable optical drives.  The
>>first drive I've installed is a Ricoh RO-5030E2, and I'm
>>surprised at how slow it is writing. 
>
>[benchmark]
>
>>Is this typical of erasable write speeds?  I expected them to be
>>slow, but not this slow!  Even removing a file from a directory
>>seems to take a long time while it updates the directory entry.
>
>magneto-optical recording has a problem: before writing data to
>a spot that spot must first be erased. that means if you want
>to write a block, it takes at least one full revolution + 1 block
>of the disk. on average 1.5 revolutions are needed, which causes
>the slow writing you experienced.
>

It also depends on whether the driver is doing a WRITE/VERIFY on 
all writes. ( This SHOULD be the DEFAULT, but it is slower. ) 

ANSI formatted Magneto-Optical disks have a Primary and a Secornday
defect list. The Primary defect list is built when you format the 
disk. If a write verify is done, then a read is performed using only
half of the error-correcting code capability. If it can be read, that
ensures that you still have some head-room in the ECC to protect you
from future data loss. If it gets an error on read, then a replacement
block is allocated and written, and the bad block is entered into the
Secondary Defect List.  

This is done on a SCSI WRITE/VERIFY command, or if the default for ALL
WRITE/COPY/etc. is set to WRITE/VERIFY with a SCSI SET MODE.

I don't know how may steps (reads/writes) are involved or if the
controller caches any of the lists, but it sounds like quite a bit 
of overhead. 
The erase before write is necessary because the laser switches 
faster & focuses finer than the magnetic field. When a spot 
is heated by the laser, and then cools, it adjusts its polarity to the 
magnetic field. If you needed to focus the magnetic field to write
succesive 1/0/'s, you would need the type of head distance that a 
Whichester has.  So instead, it writes a whole sector to zero, switches
the field, and selectively writes the ones. Some software can do 
pre-erasing and manage a list of available (erased) blocks. 
So worst case is: ERASE SECTOR, WRITE SECTOR, READ SECTOR, (ERROR),
 READ DEFECT LIST (to find next available replacement block), 
 WRITE REPLACEMENT BLOCK, READ SECTOR (verify again), WRITE (update)
 DEFECT LIST. ( The *really* bad news is the SEEKS implicit in the 
 above! Some drives MAY be able to do a read during write - that way you
 only pay a penalty when there actually is a write error - the best of 
 all possible worlds! ) 


If you are using the MO disk as a scratch device, you can probably turn
this off. If you intend it to be used for Archival Data Storage, you 
should be using the WRITE/VERIFY. 
Pinnacle's disks for MS_DOS DO NOT do WRITE/VERIFY. ( They were more 
interested in improving their performance specs, than in keeping your data! ) 
Their disks & drivers for MAC and UNIX ( I have been told ) have the 
mode as a user selectable option. ( I don't know what the default is.)

*********
 I am going to try to prepare a horror story (posting) about what can
 happen to you with improperly formatted MO media. The contents of my disk
 got up and moved 31 sectors to the right ( boot block, FAT, Directorys
 and all ! ) !
*********

frontah@rpi.edu (David J Sotnick) (06/28/91)

IBM's new MO drive uses a three pass process,  for write, and the usual one
pass for read. The three-pass write is an 1) erase 2) write 3) verify.

I'd be interested in seeing what kind of seek times you get with this one.
Spec lists speeds of 60 ms (I think) access time (1/3 of the media sweep
I think). The drive is SCSI-2, and lists for less than pinnacles's 3.5"
drive.

David Sotnick
frontah@rpi.edu

jt34@prism.gatech.EDU (THOMPSON,JOHN C) (06/28/91)

Check out the new HP drive scheduled to be in production end of this year.
At COMDEX it was running over 450 KB/sec transfers.

-- 
THOMPSON,JOHN C
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jt34
Internet: jt34@prism.gatech.edu

iverson@xstor.com (Tim Iverson) (06/29/91)

In article <1991Jun25.160859.16313@murdoch.acc.Virginia.EDU> sdm7g@Virginia.EDU writes:
>In article <1991Jun15.173019.27914@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes:
>>bill@camco.Celestial.COM (Bill Campbell) writes:
>>to write a block, it takes at least one full revolution + 1 block
>>of the disk. on average 1.5 revolutions are needed, which causes
>>the slow writing you experienced.
>
>It also depends on whether the driver is doing a WRITE/VERIFY on 
>all writes. ( This SHOULD be the DEFAULT, but it is slower. ) 

Yes, but that's not all you need.

>disk. If a write verify is done, then a read is performed using only
>half of the error-correcting code capability. If it can be read, that
>ensures that you still have some head-room in the ECC to protect you
>from future data loss. If it gets an error on read, then a replacement
>block is allocated and written, and the bad block is entered into the
>Secondary Defect List.

Sounds like you're talking about the Sony MO.  Note, that reallocation
won't happen unless the AWRE bit (automatic write reallocation enable)
is set.  I'm pretty sure it is not on by default.

Also, this definitely does not happen on a MaxOptix Tahiti.  Failure of the
verify pass and AWRE does not cause a reallocation.  I don't know about
other MO's, but this is an area in which many drives are a little bit
squirrelly - they toe the line in name, but not in fact.  Check your drive
documentation to be sure before relying on this method.

>this off. If you intend it to be used for Archival Data Storage, you 
>should be using the WRITE/VERIFY. 
>Pinnacle's disks for MS_DOS DO NOT do WRITE/VERIFY. ( They were more 
>interested in improving their performance specs, than in keeping your data! ) 

Small plug: Storage Dimensions does enable verify after write by default for
MO devices (user selectable for all devices).  We also handle the reassigns
(they happen, but very infrequently) by hand; i.e. the driver turns off
AWRE, fields the error, and issues the reassign itself.  This way your data
stays healthy even if Rocky & Bullwinkle designed the device's AWRE code.

> I am going to try to prepare a horror story (posting) about what can
> happen to you with improperly formatted MO media. The contents of my disk

Actually, the worst problem isn't formatting - good software can solve that
one - it's contamination (dust).  If you leave your cartridge in the drive
when you turn it off (or even when on but not in use), the metal jacket
stays open and dust collects.  This causes read/write failures that really
shouldn't fail, which causes blocks to be reassigned that don't need to
be.  Pretty quickly, you'll run out of spares and then you're SOL.

Keep your cartridges clean folks!  Software can't fix this problem for you.


- Tim Iverson
  iverson@xstor.com -/- uunet!xstor!iverson

src@scuzzy.in-berlin.de (Heiko Blume) (06/30/91)

iverson@xstor.com (Tim Iverson) writes:
>Actually, the worst problem isn't formatting - good software can solve that
>one - it's contamination (dust).  If you leave your cartridge in the drive
>when you turn it off (or even when on but not in use), the metal jacket
>stays open and dust collects.

that means if you dare to actually use the cartridges,
they'll get contaminated?! if the drive is constructed
so that dust can reach the inserted cartridge, it's
not worth a cent. i mean, the cartridge is *meant* to
be in the drive...
-- 
   Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!]
              public UNIX source archive [HST 14400 V.42bis]:
        scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
                     uucp scuzzy!/src/README /your/home