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

To: Sector Investor who wrote (511)	8/22/1999 4:19:00 PM
From: Frank A. Coluccio	Respond to of 626

Sector, no one is looking for you to shut up. "Try taking ONE (repeat ONE) 300GB file off of there (driven by ONE (repeat ONE) address space or application) and getting the data out at those speeds." What if I told you that this particular - this entire - storage complex was designed separate from the remainder of the enterprise's storage requirements, with only ONE (repeat ONE) e-commerce application in mind? Would you then find that more believable and acceptable? To go beyond this description would not be prudent for me at this time, in fact I may have already gone over the line. Suffice it to state that there will be many more applications like this going forward as bandwidth costs come down, and as both multimedia entertainment and e-commerce initiatives heat up. It's been fun. But I must admit that I've lost site of what the original issues were. Regards, Frank Coluccio

To: Sector Investor who wrote (511)	8/22/1999 5:17:00 PM
From: ahhaha	Respond to of 626

The speed constraint is limited by these factors: I/O bus speed, bus to net transduction, net speed. The best desktop's I/O busses run at about 100 mbps. This is orders faster than cable modem, but it is orders slower than SR. No one is proposing that there is any utility in transferring a 300gbyte file. Is there any utility in creating one in this era? The idea is that if you can send one that tall, you can send one that wide. Where is the utility in wide? The utility is found in the commonality of the trunk. It is cheaper to build one big pipe than it is to build many little ones. The issue is can all the little ones be preserved when they're dumped in the big one? This isn't a water pipe coming from the reservoir in the mountains where differentiation of content is superfluous. The term aggregation has arisen. In a campus environment where 100 meg graphics files are flying all over the place it is too expensive to construct a network of n(n-1)/2 connections between n users. It is cheaper to build 2n+1 connections between them. The only problem is that 1 dangling out there. It has to support the nm unit time throughput at any time where m is the expected maximum use per user. No technology can aggregate that much bandwidth within the campus budget except SR. If the net, the bus, the processor, all had the same speed, the issue of huge file sequential transfer would be moot. No one wants to pull FTTC. No one wants optic processors and busses. No one wants to pay for something that isn't yet needed. In some environments this capability is needed and is needed now. Where it is needed, companies like SR and SGI are looking for a chance to supply it. So the answer to your question about how fast a file can be sent in the intended work environment depends on whose intention, the work, the environment, and the depth of pocket. The answer you want though is something like the I/O bus speed of electronic silicon-based computers.