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 : How high will Microsoft fly? -- Ignore unavailable to you. Want to Upgrade?

To: TigerPaw who wrote (46170)	6/7/2000 11:22:00 PM
From: rudedog	Read Replies (1) \| Respond to of 74651

TP - it is exactly those points that I take issue with. Intel had talked about the "6th load" - an additional high speed interface in addition to 4 processors and memory. That would be the chipset mod you were discussing. But it was the need to do 8-way machines and the related memory bridging that killed the "6th load", not anything to do with 1394. And there was nothing specific about 1394 - that port was to enable a whole class of high performance peripherals, 1394 would have been low on the totem pole in performance requirements. I expect that concept to surface again in a future chipset design, maybe McKinley. Likewise, the notion that 1394 performance is in any way limited by the current implementations is just wrong. I can easily drive several 1394 channels to capacity with plenty of I/O bandwidth available. The 1394 bus could not run any faster - I can drive it beyond the theoretical maximum. And MSFT actually did a lot to make that possible - through their sponsorship of the VI architecture, which takes the OS out of the loop for VI components. From app request to data on the 1394 bus can occur with less than 2000 instructions - and with an 800MHz processor, that is not a lot of time, about 2.5 microseconds. By comparison, it takes 1394 25 microseconds to move a single byte of data. So total I/O queue and app latency is only 1/10th of the time it takes to actually send the first byte of data. Not exactly an important performance limitation. Peer-to-peer communication over a PCI bus does not require any software from MSFT - it is done all the time. CPQ does redundant load-sharing disk arrays and NICs and Fibre-channel controllers - the OS does not even know they are there. So the notion that MSFT somehow made a decision to "keep the PC in the loop" just does not hold technical water. But more importantly, there is also nothing which keeps 1394 peripherals from talking to each other in today's environment, or yesterday's. I could write drivers to have a tape device interface directly with a 1394 disk in a day - it's child's play. MSFT has nothing to do with that - it would be up to the IHVs doing the hardware and driver design. As I said, that is done today with fibre devices, and there is nothing to keep it from happening in 1394. I think the more likely reason that the plans for special 1394 support were dropped was that they add nothing to 1394 performance or versatility, so what's the point? I think your friends led you down the garden path on this one.