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: DownSouth who wrote (25167)	5/22/2000 10:16:00 PM
From: buck	Read Replies (2) \| Respond to of 54805

Applications need not be modified at all to implement a NAS filer if those applications are able to use NFS (UNIX) or CIFS (Windows). And therein lies the problem...most applications (I have no idea how many or what percentage) do nothing more than SCSI reads and writes. Converting to NFS/CIFS is not a small problem, at least not based on the experience of customers I've worked with. And certainly not for applications that move large amounts of data at a time. And should they convert, they will suffer from performance degradation imposed by IP processing and UDP processing, specifically packet segmentation and reassembly for blocks of data that are more than 1.5K in size. All of that occurs with the host processor, not down in the hardware. And it doesn't matter whether it is ethernet, FDDI or ATM. It's still an IP implementation, with UDP on top of it. And RE this statement: Communications with storage devices in NAS is via SCSI and/or FC--NOT TCP/IP (Ethernet). The LAN, whether via TCP/IP, FDDI, or ATM, is the communications pipeline between the application host and the NAS filer. So tell me again why I should stick two extra potential bottlenecks between me and my data if I am an application doing SCSI reads and writes? Step 1 is the NFS implementation (that invokes a longer application code path), and step 2 is the ethernet media that runs at 1500 bytes per packet (and require segmentation and reassembly at each end of the connection.) That is literally the way it works. 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. These fit very nicely in 1500 byte packets. But there are still plenty of applications where ethernet, IP and UDP limitations are simply unbearable. buck