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