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.

Strategies & Market Trends : Gorilla and King Portfolio Candidates -- Ignore unavailable to you. Want to Upgrade?

To: buck who wrote (25172)	5/23/2000 9:55:00 AM
From: DownSouth	Read Replies (3) \| Respond to of 54805

The SCSI interface is a function of the OS, not the application. The application is issuing reads, writes, inserts, searches, deletes, etc. The OS, then determines the platform on which the app's data resides and uses that interface. That is why NFS was "invented" by SUNW--so that a file system could be on the local drive attached to the server on which the app resides or on a network drive. That is why MSFT invented CIFS--so that a file could reside on the local PC drive or on a network attached Windows file server. I don't get your point, unless you are referring to proprietary platforms other than UNIX or Windows. WRT UDP and IP processing, first of all, UDP is obsolete, as I recall, though still supported for some legacy apps. Second of all, the bottlenecks in a multiuser, data intensive application environment are potentially many and can exist in the disk subsystem, the OS, the network, and the application code itself. NTAP remedies the disk subsystem bottleneck (whether NTAP is configured with SCSI or FC) by providing a much more efficient means of writing data, reading data. That's a fact proven time and again by NTAP and its customers and prospective customers. Solving the disk subsystem bottleneck will almost always result in finding the next bottleneck, such as the communication pipes between the app server and the data server. Solving that bottleneck is easily solved by providing more and or faster ethernet cable segments between the application server(s) and the data server(s). Often the potential bottleneck created by the speed of the application code itself is avoided by implementation of the NAS concept, as the platform on which the application resides is suddenly doing less work. It is no longer managing data or doing disk I/O. If there is a bottleneck on the app server, then apps can be distributed to more app servers and/or more powerful app servers, because the problem becomes a compute bound problem as opposed to an I/O bound problem to solve. The reason you should "stick two extra potential bottlenecks between me and my data if I am an application doing SCSI reads and writes" is simply because NTAP's NAS usually eliminates the bottleneck created by general purpose OS and the Windows or UNIX file layouts and I/O methods. You may discover a new bottleneck in the network communicating between the app server and the data server, but that is usually cheap and easy to solve. Here is a NetBench benchmark to demonstrate the fact: netapp.com Other reasons to replace SCSI file systems on general purpose computers with NTAP NAS: 1) Reduce the total number of application servers being supported. 2) Consolidate data from multiple servers to a single server. 3) Reduce sys admin costs. 4) Improve reliability. 5) Improve data security. 6) Provide an easy, inexpensive method of growing storage capacity without operational interruption. Buck, you remind me of the main problem that NTAP reps have had in selling their product. The prospect just can't quite accept the story on faith. The NTAP rep will then do the following 1) provide a customer reference who will attest to what NTAP claims; 2) provide an evaluation unit so that the prospect can see the results in their own environment using their own apps, data, and network. The result is usually a sale and a customer who now "gets it".

To: buck who wrote (25172)	5/23/2000 11:27:00 AM
From: Thomas Mercer-Hursh	Read Replies (1) \| Respond to of 54805

One reason that NAS is so successful is that data movement requirements are dropping as we move to a single-user, single-transaction model served over the web. But, by the same token, web-based applications often produce scalability issues far beyond those with fixed endpoints. I would be interested in the two of you commenting on two issues, derived from my general background in systems performance, not from specific knowledge of these technologies, but which seem like they might be relevant. First, ethernet connections are not just limited by total bandwidth, but also by competition for that bandwidth. When there are a large number of users competing for the bandwidth, the resulting collisions and retries can lower the effective bandwidth quite dramatically over what the pipe could theoretically carry. SCSI, by contrast, is a much more managed protocol and can deliver sustained performance close to rated bandwidth when properly implemented. Is this contrast an issue in this debate? Second, some storage architectures deliver excellent read performance, but are highly undesirable when a significant portion of the activity is writes. E.g., RAID 5 and a high transaction database are generally a very poor match since either write performance is poor or integrity compromised. Is there a difference in these architectures between read and write performance?