Plextor SCSI drive... anybody?

I guess you all read the news on the frontpage, that Plextor is about to release a new CDRW drive with SCSI interface, somewhere next year.

So I am wondering: who is planning to buy this device? I know I certainly am! Last summer I replaced my Plextor 12/10/32SCSI with a LiteON 40/12/48 @ 48. Although the LiteON is really a nice drive, I still miss SCSI… IDE just costs too much CPU power.

Someone who has high CPU load due to IDE usage should repair his Windows or use better chipsets, SCNR

P4 2900, 48x writing: up to 5% CPU load.

Dee-ehn,

Current IDE devices use UDMA, which requires only low percentages of CPU usage.

Basically, DMA takes the CPU out of the loop and allows direct communication of the IDE device with system memory. The CPU is not required for this access.

Of course, there’re problems:

Mainboards with KT133A chipset and 686B southbridge cannot use UDMA on the 2nd IDE channel if a soundblaster live is installed…but even then, you can still use MW-DMA, which is enough for about 9x DVD speed, and which won’t cause CPU load either.

I know they use UDMA nowadays (doh), but there is still a difference between SCSI or IDE. When burning at 12x with my SCSI writer, the CPU load is lower then when burning at 12x with my IDE writer.

Alexnoe: I know there are problems with certain KT133x chipsets combined with a SB live. However, I had this combination more than a year without any problem. About half a year ago, I threw out the Live and exchanged it for an Audigy card (Firewire!), no problems there either. And guess what, my second IDE is also working in UDMA mode… (it was the same with the Live on it btw).

Put one more on the list; I want the SCSI too. :slight_smile:
I always had SCSI. Back in the old days, all writers were SCSI (I’m talking about a few years after the last ice age ;))

I still have a SCSI HP6020, Plex4/2/20 and Plex12/4/32 (and some Plex SCSI readers). Due to the official Plextor announcement that they had quit making SCSI devices, I was forced to buy a Plex IDE (40/12/40). It’s still a good writer though, but I agree with Dee-ehn; SCSI is what I prefer :slight_smile:

It’s not just the CPU or memory usage, but also the high quality components and euhm “quite fast” transfer rates ;). No IDE ATA133 setup can get close to a 160MB/sec or 320MB/sec SCSI chain. OK, for normal use, you won’t see much difference between a 40x IDE copy and a 40x SCSI copy.
But when using the same PC for ripping a DVD, scanning some images, editing and printing those images while burning to 2 or 3 writers at the same time, I won’t like to count the times burnproof kicks in for an IDE setup. Or getting major hangups.
I already know how many times for SCSI: 0 :wink:

Just my opinion. I’m sure lots of you don’t agree, but hey, it’s a discussion board :slight_smile:

When burning at 12x with my SCSI writer, the CPU load is lower then when burning at 12x with my IDE writer.
This can be caused by crappy chipset drivers (I thought you had no problems? Well, this is a problem). Again: use better chipsets…

No IDE ATA133 setup can get close to a 160MB/sec or 320MB/sec SCSI chain.

Of course you know that KT133A chipset can get not more than 65 MB/s through its buggy PCI bus, so 160 MB/s is nothing but a sweat dream on such a system.
Chipsets without such bugs get somewhat over 100 MB/s, but 160 is still far beyond what’s possible. That can only be reached on 66 MHz PCI busses, which you only find on pretty expensive boards (the cheapest one I know is a Tyan dual athlon board for about 350 euro).

This kind of discussion is always the same: None of the SCSI-pro-people knows more than the theoretical maximum throughput :slight_smile: (well, there are a few in the german burner and hard discs newsgroups, that they are 5 at most)

I agree that more than 2 writers which are intended to be used simultaneously require SCSI, because of the lack of disconnect/reconnect for IDE; but this is the only reason. The whole thing about higher throughput is crap for any system “normal” users are willing to afford
BTW “current” SCSI writers (Plextor, Yamaha 16x-24x; no idea about 44x) use a protocol which allows 20 MB/s.

Mainboards with KT133A chipset and 686B southbridge cannot use UDMA on the 2nd IDE channel if a soundblaster live is installed…

Alex, I have this exact setup, and am getting 48x speeds, including on-the-fly CD copies across the secondary channel.
UDMA is functioning very well I’d say.

And you are sure that no data is changed during copy? In this case, I’ll google a bit.

But I’m 100% sure that this combination can cause data to be changed during transfer. I’m just not sure if there are more requirements to cause this effect.

Could you define “changed data”? I have copied Win2K CD and used it to install, no problems. Other software copies have also worked fine. Of course I don’t do critical copies at 48x, maybe 32x to be “safe”.

Change data means:
Source and destination disc are not identical then.

However, the amount of data that is changed can vary, but if you copy the same large file again and again on a hard disc for a complete day, the final file will be complete crap if the bug is present.
It has nothing to do with the speed you burn at. It’s a UDMA bug. Changing to multiword DMA should be a sufficient workaround, if the bug occurs.

Is this something that “verify” in Nero would pick up?
This also concerns me because I do a lot of HD imaging and copying, but only on the primary channel.
I don;t think i have the “multiword DMA” option.

“verify” would pick it up.

The primary channel should not be affected, as to my knowledge, but that is IMHO only…

You must make the drive report “PIO only” (such as the anti-DMA jumper on Plextor 24x) and then set to DMA in windows. The result will be multiword-DMA.

Setting the drive to PIO in BIOS might be ignored and might not cause the drive to be run in multiword DMA.

Anyway, even with mutliword-DMA only, SCSI would not gain any advantage over a single-burner setup.

My BIOS reports 2 DMA readings:
“Synch”, which indicates Multi-word DMA-2, and
“Ultra”, which indicates UDMA-2

Windows bypasses the BIOS for accessing the drives, so that BIOS settings are likely to be overrided in Windows.

Originally posted by alexnoe
This can be caused by crappy chipset drivers (I thought you had no problems? Well, this is a problem). Again: use better chipsets…

Strange… my KT133A outperforms my SiS chipset on my P4 system.

About a multi burner setup: my system counts 3 burners… 2x SCSI and 1x IDE. If Plextor comes at the right moment, perhaps it will be 3x SCSI…

(1) Which KT133A vs which P4? Of course you know that P4’s need a much higher clock frequency than an Athlon for the same performance :stuck_out_tongue:
(2) Do you use your burners simultaneously?

Maybe I don’t know more but the max throughput, but that counts for IDE too. IDE = 133max, but it’s all about the sustained throughput, which is one of the advantages SCSI offers. IDE can give high peaks, but drops to “nothing” in no time. While SCSI offers a constant throughput for each device.

That’s why capturing video was only possible on SCSI-discs. IDE-discs started dropping lots of frames after a few moments capturing. However, IDE is catching up on SCSI, but not as fast as most people think or would like to hear.

I’m not saying everybody should use SCSI, but I sure do. (the lifetime for SCSI discs compared to IDE is one of the other reasons)

IDE = 133max, but it’s all about the sustained throughput, which is one of the advantages SCSI offers
No.
IDE can give high peaks, but drops to “nothing” in no time.
This statement contains so few truth, it could be copy+pasted from tomshardware :frowning:

Again: SCSI will be limited by PCI throughput, unless you have a board with 66 MHz PCI.

That’s why capturing video was only possible on SCSI-discs. IDE-discs started dropping lots of frames after a few moments capturing.
That’s again totally wrong. Capturing to IDE was impossible because of the lack of DMA lots of years ago. And the transfer rate of IDE drives itself was too low. This had nothing to do with IDE, but simply with cost of faster drives.
It’s still the same today: It would be absolutely no problem to build a 15.000 rpm IDE drive with 5ms access time, but only “SCSI-people” are willing to pay the exorbitant prices for these drives. That’s why they are not made for IDE.

About the lifetime: Seagate Barracuda ATA II and IBM DTLA/IC are crap, but I don’t see any problem with the lifetime of other IDE hard discs.

Originally posted by Inertia
[B]Dee-ehn,

Current IDE devices use UDMA, which requires only low percentages of CPU usage.

Basically, DMA takes the CPU out of the loop and allows direct communication of the IDE device with system memory. The CPU is not required for this access. [/B]

While the drive is using DMA (EVEN udma) the cpu cannot access the RAM bus. This means that even though the CPU is IDLE, it can’t actually do anything, unless the program and all required data is already in the processors cache. Hence, programs will not detect a high cpu use, but it really is because the cpu just can’t do anything anyway.

So Actual throughput in the system will be much slower with IDE than SCSI.