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: OrionX who wrote (2637)	6/13/1998 12:20:00 AM
From: Cris	Respond to of 5944

> One more thing I keep forgetting is Adaptec's network products, > ATM and Ethernet related. Unfortunately, I'm not familiar with > their penetration of these products in the general marketspace. > Any info, market wise, any of you can provide on this? Well, back when 3Com tanked a while ago due to some Intel price cuts, and ADPT was mentioned as being in the NIC biz, ADPT mgmt was reportedly calling the analysts to tell them that the NIC business was tiny, so not to worry. ATM never took off, and I don't think anything's going on there. The Cogent acquisition should be enough to worry anyone optimistic about Symbios. ADPT bought Cogent, who sold Enet boards based on commodity (Digital) chips. The plan was to sell high-margin 'server NICs'. For some reason, customers did not appear interested in dropping the 3Com and Intel NICs that seemed to work fine. Also the 'server NICs' did not have SNMP support for quite a while. So they never had much share of a small TAM. A search of the ADPT web site finds no mention of any plans for Gigabit Ethernet. Cris sad, but still long (recent lack of volume is scary) <not speaking...>

To: OrionX who wrote (2637)	6/13/1998 8:08:00 AM
From: Mark	Read Replies (1) \| Respond to of 5944

Mauro, I suspect the performance differences you have observed are related more to software than hardware. The script's driven EIDE controllers are much newer than the SCSI ones, and I suspect that the OS drivers need time to catch up. There is no physical reason why in a single disk implementation there should be any difference between the potential of SCSI or EIDE - i.e. the physical limitation is the medium (bit rate on the disk and head dynamics). However, I do agree that clear performance differences exist in the PC space between the two, but will re-iterate that with decent software it need not be this way. I cannot make any legitimate comments about CDROM & scanners (though I might expect the differences noted above to be more significant because the items are slower). Finally - there was an excellent post of comments in the last CC earlier (start of May ?). I think that gave a clearer picture about market breakdown. If I recall correctly, SCSI was around 50% by revenue but you should find that post for more info. Mark

To: OrionX who wrote (2637)	6/13/1998 1:02:00 PM
From: R2O	Read Replies (1) \| Respond to of 5944

Some technical comments re SCSI/EIDE: viz: advansys.com for general comments. Probably other good stuff there also. WRT ADPT stock: don't know at what price, but seems like a stock one should be long. SCSI isn't going away and neither are the other areas ADPT deals in. They have placed themselves, with Symbios acq (and others before) into being in the right place for SCSI, for sure. Will they keep the complete Symbios fab line? Probably not. I say this only because sinking enough money into a bleeding edge fab line with their level of business will probably be a losing proposition. I haven't seen much of a need on ADPT part to build image at the expense of real profits, so I would guess that someone really evaluted the Symbios purchase carefully. I am not comfortable with the 'low' cash position after Symbios. Hard times need cash. (What hard times? you say.) Now for long winded technical comments: Click Next. A mention was given re 'script based' EIDE. I would guess that this has to do with something akin to the way SCSI script based controllers, eg NCR 880 PCI/SCSI, do their magic. (or just something like the required SCSI command block structure?) (Sorry, don't know about Symbios chips, but guess they're about the same.) In the NCR880 case, the interface chip does all the actual processing, simply getting it's instructions from Host memory (or it's local cache or it's local ROM or ...) No Host CPU involvment is required except to set up and point to correct blocks of 'script'. The chip itself has a script/command language beyond the SCSI Command blocks, which all SCSI devices support. Similarly, data can be/is transferred to the final destination --- ie the chip can do 'scatter-gather' operations ... if the OS would only let it. The Host CPU need not be involved in any of this. Also, multiple SCSI devices on the same bus can be accessing/seeking/whatever at the same time, overlapping slow mechanical operations with data transfer from another device. SCSI also allows for logical units within SCSI devices. SCSI also allows for a wide variety of 'devices', such as processors, memory(?), etc. that I don't think are on (E)IDE's list. The ability to disconnect/reconnect and the inherent multi-tasking of the SCSI model (the SCSI model is inherently a multi-device<->memory mapping) allows SCSI to easily outperform EIDE, IF EVERYTHING ELSE IS DONE CORRECTLY. I would also guess that PCI implementations of EIDE make some compromises. Modern SCSI chips are built from the ground up with PCI in mind. Caching/read-ahead, etc., can be done everywhere along the SCSI chain, from the Host memory out to the device. No Host CPU involvement is logically required. As far as I know, (E)IDE drives may or may not have local drive cache, managed however they feel is appropriate. With the low cost of memory (size and $), I would hope that all drives at least slurp the entire physical track the heads are over. Need not add any time. The interface may or may not also have cache. No laws against any of this. With regard to 'track level' control, neither a SCSI nor IDE disk permits you to have access to the PHYSICAL arrangement of the disk, although you can send it messages that look like you have such control. The device itself keeps all the real PHYSICAL configuration to itself --- I don't think any modern discs use fixed sectors/track anymore, all remap bad sectors all by themselves. Maybe you can get a list of bad sectors, maybe it has something to do with the actual physical location of the data --- maybe not. All that need be true is that it there is a map in the drive that lets it understand the parameter you think of as sector/track. Some 'user accessible' sectors may not even correspond to places on the physical media, e.g. they may be parameter/code areas for the local device controller and be located in flash memory. You ARE guaranteed that if you put a block of data someplace you can get it back. That's it. Ah, the wonders of firmware. From an actual performance point, the less the OS gets in the way, the better. No matter how great the underlying HW/Firmware is, it's very easy to wreck it's performance with thoughtless SW, or a poorly conceived OS. In short, WRT performance, like any other general statement about what is likely to be 100K lines of code in any given actual application, the proof is in the real world measurements. Try it out and see what happens, but you have to really instrument with physical things, such as SCSI bus monitors, real time code probes, etc. to see e.g. that your disc drive, when asked to xfer a 4K byte block of data is, for private reasons of it's own, various size transferring bits and pieces with lot's of overhead. Benchmarks must really simulate the requirements of your application. Sorry for the blather. May your doctor never be 'blue screened' while operating on you.