From owner-freebsd-hardware Wed Jul 3 13:32:15 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA23065 for hardware-outgoing; Wed, 3 Jul 1996 13:32:15 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA23029; Wed, 3 Jul 1996 13:32:05 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA15101; Thu, 4 Jul 1996 06:27:05 +1000 Date: Thu, 4 Jul 1996 06:27:05 +1000 From: Bruce Evans Message-Id: <199607032027.GAA15101@godzilla.zeta.org.au> To: msmith@atrad.adelaide.edu.au, stesin@elvisti.kiev.ua Subject: Re: muliport boards - building a PPP dialup server Cc: Kevin_Swanson@blacksmith.com, cofer@www.cas.unt.edu, freebsd-hardware@freebsd.org, isp@freebsd.org, michaelv@HeadCandy.com Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ># I'm curious - why PCI? > Something makes me beleive that if I want more than 16 ports > at 115200 per box, there would be two bottlenecks: > 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. No, interrupt load is large. Serial hardware interrupt overheads (for drivers with fast interrupt handlers like sio and cy) are not counted because the drivers mask statclock interrupts. The overheads are added to the overheads of whatever happens to be running when the serial interrupts occur. On a 486DX/2/66 with 16550s (non-multiport; add 25-33% to interrupt overheads for multiport) or cd1400s, the overheads are approximately: source overhead relative ------ serial interrupt overheads 3% per 11KB 1 system overheads for termios raw mode input 3.3 1 system overheads for cslip input 3.7 1+ system overheads for pppd input 6.1 2 system overheads for termios cooked mode input huge (50?) 16 The system overheads are easy to reduce by replacing the 486/33 with a Pentium. The interrupt overheads are mostly I/O overheads so they are hard to reduce because boards with fast I/O are hard to find. > "Smart" card with it's own CPU (I treat it like > an I/O co-processor) should minimize this factor. (?) Only if the driver supports the smartness. This isn't easy, because the upper tty layers want to do their own line discipline processing. None of the FreeBSD serial drivers supports smartness. > 2. ISA bus itself, no matter what will I put into it. This is the main bottleneck on anything faster than a DX2/66, at least if 8-bit I/O is used. The overheads for Comtrol RocketPorts would be about half as small because RocketPorts support 16-bit I/O. Bruce