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 : Network Appliance -- Ignore unavailable to you. Want to Upgrade?

To: sailboat54 who wrote (4060)	8/17/2000 11:09:32 AM
From: DownSouth	Read Replies (2) \| Respond to of 10934

If you mean "why change from Alpha to Coppermine", then the answer is that CuMine is a faster CPU than Alpha, increasing the overall throughput of the filer. If you "why add a second CPU to the motherboard", then the answer is that if NTAP is re-engineering the ONTAP OS to take advantage of a multiprocessor architecture, the the second CPU will increase the throughput of the filer. I suspect that NTAP has plans for a multiprocessor architecture. There are several approaches to this, and I do not know which they are taking: 1) True co-equal multiprocessing where the processors share the work on an equal basis, parsed by the OS. 2) Slave/master multiprocessing, where one processor is the master, and, in conjunction with the OS, parses work to the second CPU. 3) Specialized multiprocessing where each processor is responsible for a specific set of tasks. For example, the second processor may be a dedicated I/O processor, responsible for controlling the I/O subsystem and all aspects of moving data from main memory to the I/O bus and vice versa. 4) "On board clustering" (my term) where each of the two processors have their own RAM and perhaps a NUMA connection between them working almost identically to the current two-filer clustered fail-over configuration. This would be akin to the old Tandem computer architecture, which is where NUMA got its start. This approach by NTAP would probably require less re-engineering of the OS and offer a level of failsafe redundancy and reduced cluster failover configuration cost. I don't know what approach NTAP is taking.