SI
SI
discoversearch

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 : Silkroad

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Frank A. Coluccio who wrote (507)8/22/1999 1:21:00 PM
From: Sector Investor  Read Replies (1) of 626
 
<<You may want to do some perusing of EMC's enterprise storage capabilities.>>

Frank, you keep going around my point (about the weakest link in a chain).

Yes, a 300GB file CAN be stored on disk - 16 PHYSICAL disks to be exact, using your EMC link. I'll ignore the fact that no SANE enterprise shop would elect to store files that size on disk, unless they had frequent need for fast data access to it (ala database, or SGI's special case).

OK, the file is on disk(s). How fast a data rate can you SUSTAIN in getting that file transferred? What is the EMC data transfer rate? ESCON channels are 200Mb/sec I believe - and that assumes NO ONE else is using it. How do you get the data to , say an OC-12 or OC-48 link without using multiple channels? Can one application even USE multiple data channels at a time for a single file transfer?

Multiple users can AGGREGATE that much data and more, but a single file transfer approaching those speeds under normal loads requires that the whole architecture be designed with one high speed user or application in mind.

In a server environment you have other weak links.

I repeat. It will be years before we can ROUTINELY transfer that much data from a storage device, across bus/channels, at a SUSTAINED rate approaching Silkroad speeds.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext