CD-RW question

[rivethead]

This probably sounds a little far fetched but it's worth a try. Is it possible at all to overclock the read/write speeds of a burner? Thanks alot guys.

[mantapc]

I really doubt it...

[HAL9000]

No. There are some rare instances where a firmware to a faster drive can be used on a slower one to upgrade it, but I wouldn't recommend it unless you are willing to risk permanent damage to your CDRW.

[rivethead]

Oh, well it was worth a try. Thanks anyway fellas.

[Toaster]

Hello folks,
The term "overclocking" when applied to devices OTHER then a CPU does not actually apply. In the IDE world of devices, the crystal (oscillator actually) needs to stay close to the intended frequency or the IDE bus goes nuts.
In the SCSI world however, things are quite different.
Iv'e "cranked up" SCSI devices of most kinds. The oscillator on SCSI devices is directly relative to the performance of attached devices.
Bus timing in any interface is often critical. On the IDE interface, the bus timing is ultra critical. Too high and the interface will try for too much time on the bus and the device may never report "ready". Too low and the device is slow to respond and accept an inquiry or drops "ready".
In the SCSI relm, things change markedly. The oscillator "limits" the transfer rate and the amount of time the SCSI bus to memory time.
Often, on SCSI-2/3 devices, this oscillator is fixed at 20/40mhz. This figure is the peak data bandwidth the device was designed for.
Some devices are set to low figures because the device can't make the full jump to the next and remain "active". Some devices are set "high" and thus the device fends for itself. However, this is somewhat rare because the device must have a large data cache to keep the bus active while the device seeks/executes the next command in the que.
On IDE devices, the oscillator is fixed at a frequency so that each device can "communicate" at the same rate. Disturb this communication and you get data read/write errors and gross corruption.
IDE devices are quite "dumb" and only one device per interface can be active at any given time. That is, 2 devices on the primary controller, only 1 device at a time can be active.
You can test this by setting a CD-ROM drive as slave and a hard-disk as master on the same interface. Run an app that requires both CD and HDD.
The performance under the above situation will be far from ideal as the CPU must "moderate" which device is active and which is not.
Ideally, your HDD's would be on the primary interface and removable media on the secondary. Only in this way can both the CD and the HDD be active at the same time.
While the above is the ideal way, be warned that IDE devices being "dumb" require CPU time to "do thier duty". It is not unusual for a IDE HDD to require 70% or more of your CPU time just to transfer data from drive to memory.
I have seen 100% on many occaision!
Look at it this way:
Your system has an ATA-66 20GB hard-disk as master on the pri interface.
Your system has an ATA-33/66 50x CD-rom drive on the sec interface.
When you launch an app that requires BOTH the CD and HDD, your system performance can easily be HALF of what it should because the CPU time needed to operate BOTH devices is excessive and thus must be taken from the system bandwidth.
An Ideal set-up?
All SCSI of course!
A better set-up then typical?
A IDE/SCSI mix works very well.
IDE drives have a great "burst" rate at which they can deliver data for a short period of time. SCSI on the otherhand can maintain a "sustained" data rate.
A good quality IDE drive on the master interface and removable devices on SCSI or vice-versa.
Now, your SCSI devices require very little CPU time, often well below 10% and the better interfaces are below 5%.
Your system can now benifit from the high peak data bandwidth of the IDE device and suffer no performance hit when the CD is also active.
Properly set-up and researched, this can improve performance by 50% in many cases. Thats like a 1ghz CPU for that of a 500mhz CPU.
The IDE interface has a few major drawbacks and a few good points.
The drawbacks are what I mentioned above and the fact that all IDE devices are "BIOS" devices. That is, IDE devices are "translated" to paremeters both the system and the O/S can understand. Any time an IDE device is asked to perform a task, the following happens:
1. A call to hardware to get the device.
2. The devices paremeters are translated to a usable form.
3. The system/CPU grants Interupt/DMA time for the device.
4. The device transfers the data and releases the bus.
IDE devices are based on an age old interface many of you may not have heard of.
This interface is the ST-506 interface. This interface was designed by seagate in about 1980 to support thier then, top of the line 5 Megabyte (megs folks, not gigs!) disk drive. This interface is handled by BIOS calls.
In this, the IDE interface has undergone little change.
Sure IDE is cheap, fast in many cases and very plentiful.
SCSI tends to be about 30% higher in cost then IDE.
The "typical" system with a primary and secondary IDE interface can deal with 4 devices. SCSI on the otherhand is for all practical intents and purposes, unlimited. There are 1/2/3 channel SCSI controllers, each handling upto 15 devices per/chan. Thats 45 devices on 1 Interupt!


Sorry for the long winded babbling.....

[mike breck]

Toaster, you have the great ability to explain complicated theory in a clear and simple way...and make it interesting. You put many college professors to shame.

Thanks for another great lesson.

[jotto84]

God, I love toaster's 10-page long essays and stories to explain this technology down the bits and grits... truly an awesome member of this community

[Toaster]

Hello folks,
You peoples are too kind and I thank you.
It's simple to babble on as to whats better then what but without a bit of background, its hard to make a clear choice.
Often, its very helpful to know "whats going on" to find out how to make the process more efficient.
I am a student as well as a teacher and while I try to remain clear on a subject, I can sometimes muddy the waters so to speak.
I hope I didn't oversimplify because it reduces accuracy to some degree.
I felt, a minor reduction in accuracy was worth clarity in exchange.
There are many other "things going on" in the above example but to keep things clear I had to sacrifice some accuracy. Still, the bottom line is the same but just a few steps were ommited to avoid confusion.
Thanks again folks.