From owner-freebsd-hackers Fri Oct 20 04:33:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA29839 for hackers-outgoing; Fri, 20 Oct 1995 04:33:30 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA29834 for ; Fri, 20 Oct 1995 04:33:28 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id GAA29189; Fri, 20 Oct 1995 06:32:24 -0500 From: Joe Greco Message-Id: <199510201132.GAA29189@brasil.moneng.mei.com> Subject: Re: Bragging rights.. To: dennis@etinc.com (dennis) Date: Fri, 20 Oct 1995 06:32:24 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199510200052.UAA29399@etinc.com> from "dennis" at Oct 19, 95 08:52:48 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > Joe Greco says..... > > >Dennis started this thread on the assertion that his sync serial cards can > >do very high speeds quite easily :-) > > Actually, Dennis started this thread by trying to get a price reference for > the Async solution that Jordan referred to....I did not start it by saying > that sync is better than async. Okay, the former is true, the latter however was not implied. "Dennis _continued_ this thread on the assertion that his sync serial cards can do very high speeds quite easily" .... > My point was that if for about the same > money you can have a more flexible solution that will use less of your CPU > it is worth considering. I agree (but fail to see the "for about the same money" portion of this statement in your product). > Unlike most of you, my perspective is > marketability....not necessarily your (wrong) opinion that async is just as > good. You haven't been reading. I've clearly stated that there is a performance penalty (processing overhead, which generally falls into the category of interrupts) associated with async. There are both benefits and disadvantages. The benefits include the fact that I can go down to Moe's Computers a few blocks down the road and pick up a 16550 solution, the fact that "everybody" speaks async RS232, it's quite reasonably priced, and it's a longtime PC standard. The disadvantages are that at higher data rates it starts to eat CPU, and it's async. > If its not cheaper, which has always been the sole selling point for > async, then it's a no-brainer. Yes, I agree. But the way I count it, it's cheaper by about $370 per side (or $740 per solution) - assuming your card is $400 and a standard _dual_ 16550 card is $30ish (I do not wish to bicker over numbers however). (I notice I've been inadvertently flipping back and forth between wholesale and street prices, I'll try to stick to street prices, sorry folks.. I just happen to do most business at wholesale prices) That's quite a sell for your average consumer of PC grade systems. You can get a cheap V.34 solution (internal generic w/ 16550's) for about $110 total per side. Now you tell this guy who sees this that he can go ISDN for around $275 (Motorola Bitsurfer ext) plus $30 for a 16550, and maybe he's not happy about an extra $195, plus a more expensive monthly ISDN bill, but the total cost isn't sooooo much more than the V.34 solution and he's sold the first time he runs Netscape. He's happy, though, because he can call most places that support ISDN, and his ISP just charges him for greater bandwidth on an async terminal support. So now Dennis tries to come along and sell him a sync serial solution. The guy now forks out $400 for a sync serial card. He hooks it up and finds he can't connect to his ISP. His ISP tells him it'll be an extra couple hundred bucks a month to run their end on sync serial. So he's pissed. Then he finds out he can't call anywhere else either, because no one supports it. So he has now paid $675 for the solution (assuming the Bitsurfer can do sync serial), he HAS the extra bandwidth offered by sync serial, but he's paying several hundred dollars a month for the privilege, and he can only use it for his Internet connection. Six months down the road when he gets tired of it all, and he decides to drop the Internet thing, he finds out he can't even use his sync serial card for his mouse or printer. Cost analysis: $305 for async solution that can do 11520 bytes/sec. $675 for sync solution that can do 14400 bytes/sec. You are paying 2.2x the cost for 1.25x the throughput. In the real world: This will fly just about as well as 16.8K and 19.2K modems did. They're great if you _need_ them. But they're rotten for general public consumption. You can have the greatest, most technically elegant solution in the world. It does not guarantee you success, and it does not guarantee that people will buy it on technical merits. Look at the corpses of companies that have had great technically innovative products that went nowhere. Now look at your average PC - the grungy architecture that survived because it was quick, dirty, and cheap. Dennis, I think you have a _great_ product! This was never questioned. However, that's not the point of all of what I just described. Going back to this statement: > Unlike most of you, my perspective is > marketability....not necessarily your (wrong) opinion that async is just as > good. The marketability perspective I see is that you have a great niche product that can't be beat - within its niche. However, if you wish to butt heads with async, you're in for a real uphill battle. Async is standard. Async is substantially cheaper. Async is available at the corner store. I would not argue that async is just as good as sync - on technical merits. However, from a marketing perspective, I contend that async is _NOT_ "just as good as" sync - it's BETTER. If your marketing department thinks otherwise, you need a new marketing department. And if my opinion is wrong, I'd like to know which aisle the sync serial cards are in at CompUSA... the sales droids don't have a clue. > I have a 386DX/40 routing between a > >T1 (1.544Mb/s) and an Ethernet and it handles average mixes of traffic > >without any trouble (it runs into problems if you start saturating the T1 > >with small packets however). It is QUITE impressive :-) I don't think > >you'd need to do any crystal switches to do what you describe, since the > >board is designed to be quite flexible. However, you are probably limited to > >packet modes such as PPP (Dennis? I am extrapolating here, any solid > >info? I was never able to access raw data streams, although I only looked > >briefly) > > Its limited to whatever I wrote for it so far. There's not much market for > raw data streams. Agreed :-) > We can run 2 dos boxes back to back at 4mbs and run all > day. The overruns you're seeing with small packets is a FreeBSD/CPU power > issue in processing IP packets, and can be linearly corrected by increasing > CPU power...the capabilities are limited only by what unix can handle as the > per packet latency is fairly high, particularly on a slow box. So. From a marketing perspective.... if async is too slow due to processing power, your contention is go sync because it's essentially offloaded I/O.... if things are still too slow then get a faster box.... I know the first thing my marketing dep't would point out is to cut out the intermediate step and just get the faster box right away, since it will cost about the same as doing the intermediate step. Sorry, couldn't resist :-) (for those just joining the party, please note that I am a satisfied ET customer, and definitely would buy their products again, I am just having a bit of trouble swallowing this particular line of reasoning that Dennis is proposing :-) ) ... JG