Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Adaptec (ADPT) -- Ignore unavailable to you. Want to Upgrade?

To: Torben Noerup Nielsen who wrote (2174)	5/14/1998 5:10:00 PM
From: Mark Brophy	Read Replies (1) \| Respond to of 5944

Re: CPU speed and throughput You stated that it's a disadvantage to choke the CPU, so there's a need for SCSI. But, most of us already have excess CPU speed and Intel is funding every startup in the world that promises to make good use of the excess. In addition, Adaptec mentioned at the conference call that the falling price of DRAM mitigates the need for a fast hard disk. If you have a huge cache, why bother with SCSI? Is there any reason why I shouldn't expect continued deterioration in the low end from mother Adaptec and strong demand on the high end from Symbios and mother Adaptec? This 1394 issue is getting pretty comical. Not only does Adaptec support 1394, but Intel just dropped planned 1394 support from future versions of the 440BX chip set due to lack of demand, and they're telling customers to go to Adaptec. I'd also like to see a little research from some posters on this thread before wasting reader bandwidth.

To: Torben Noerup Nielsen who wrote (2174)	5/14/1998 8:23:00 PM
From: Mark	Read Replies (1) \| Respond to of 5944

Torben, I do disagree when you imply that IDE performance will catch up somehow. I just do not think that is technically possible. There's also a hefty CPU penalty which no one seems able to do anything about. Then again, there are reasons why few seem to notice it.... The ONLY differences between SCSI and IDE that I think are significant are that i) SCSI has stronger bus drivers which allow a better termination arrangement and therefore a longer bus with more devices, ii) SCSI is a transaction bus which allows additional operations to happen during otherwise dead periods. For users who's capacity and physical reqirements can be met with with IDE (i.e. many folks), there is no significant difference in the bus bandwidth available. Furthermore, in such an arrangement, the drive request re-ordering which can be undertaken by a good SCSI drive controller could just as easily be undertaken by the host processor, with minimal timing overhead. You also mention that the difference between SCSI and IDE starts to become apparent under NT. My experience is that any decently threaded O/S is absolutely ripe to handle the HDD device driver enhancements that could allow the out-of-order execution which would make an EIDE drive behave similarly to a SCSI (for raw drives with the same rotational speed and seek times). My point is that once you have an HDD bus interface which is significantly faster than the media rate (which both SCSI and EIDE now are), there is nothing that cannot be done on the processor/controller just as well as on the drive/controller. Your point about how much host overhead this might add is well made. However, until we get I2O, any high-performance CPU which is going to be slugged with I/O interrupts might just as well do a little more work to speed up the transfers. This is how I believe Solaris Server works (the disk transaction intelligence is with the host, not the drive). Mark