Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Oct 1995 06:32:24 -0500 (CDT)
From:      Joe Greco <jgreco@brasil.moneng.mei.com>
To:        dennis@etinc.com (dennis)
Cc:        hackers@freebsd.org
Subject:   Re: Bragging rights..
Message-ID:  <199510201132.GAA29189@brasil.moneng.mei.com>
In-Reply-To: <199510200052.UAA29399@etinc.com> from "dennis" at Oct 19, 95 08:52:48 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510201132.GAA29189>