From owner-freebsd-hardware  Wed Jul  3 07:39:28 1996
Return-Path: owner-hardware
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id HAA12984
          for hardware-outgoing; Wed, 3 Jul 1996 07:39:28 -0700 (PDT)
Received: from uu.elvisti.kiev.ua (acc0.elvisti.kiev.ua [193.125.28.132])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA12241
          for <hardware@freebsd.org>; Wed, 3 Jul 1996 07:35:26 -0700 (PDT)
Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.129]) by uu.elvisti.kiev.ua (8.7.5/8.7.3) with ESMTP id RAA02338; Wed, 3 Jul 1996 17:57:04 +0300 (EET DST)
Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id RAA04815; Wed, 3 Jul 1996 17:57:04 +0300
From: "Andrew V. Stesin" <stesin@elvisti.kiev.ua>
Message-Id: <199607031457.RAA04815@office.elvisti.kiev.ua>
Subject: Re: muliport boards - building a PPP dialup server
To: msmith@atrad.adelaide.edu.au (Michael Smith)
Date: Wed, 3 Jul 1996 17:57:03 +0300 (EET DST)
Cc: hardware@freebsd.org
In-Reply-To: <199607031402.XAA09755@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 3, 96 11:32:51 pm
X-Mailer: ELM [version 2.4 PL24alpha5]
Content-Type: text
Sender: owner-hardware@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

# Sales people are universally useless.  I almost always try to make
# contact with technical staff when evaluating a product.

	That's life... I wasn't lucky enough to get a person's
	name from them, -- but I was dumb enough to forget
	that I can look at copyright notice in the driver :-)

# > 	1. tty-level driver overhead, that's what I'm watching
# > 	   now with 16 FIFOed ports in 486dx4/100 -- interrupt
# > 	   load is tiny, and most of CPU is eaten by system.
# > 	   "Smart" card with it's own CPU (I treat it like
# > 	   an I/O co-processor) should minimize this factor. (?)
# 
# No.  None of the 'smart' cards currently around perform any tty processing.

	Won't tty-level overhead decrease when the data flow through a port
	will be going in bigger chunks?

# > 	2. ISA bus itself, no matter what will I put into it.
# > 	   We don't have any EISA slots; so PCI is left.
# > 	   (And should I mention the fact that there are boxes around
# > 	   of non-Intel architectures running unices, which
# > 	   have PCI slots but no ISA slots?)  Yes, probably I'm
# > 	   wrong and ISA can deal i.e. with 32x115200; but how
# > 	   reliable will this configuration be?
# 
# This is a significant issue.  32x115200 is ~350K/sec. presuming 100%
# efficiency.  IIRC, Bruce quoted more like 50%, so the ISA bus would be
# prettymuch saturated.  A 'smart' card with a shared-memory interface
# might be more efficient in this case.

	That's precisely what I meant.  Pentium won't help here :-)
	About shared-memory interface -- doesn't it work
	through the same ISA bus, anyway?  Yes, it will decrease
	interrupt load, but won't it keep ISA bus busy -- this way
	or another?

-- 

	With best regards -- Andrew Stesin.

	Phones/fax:  +380 (44) { 244-0122, 276-0188, 271-3457, 271-3560 }

	"You may delegate authority, but not responsibility."
					Frank's Management Rule #1.