From owner-freebsd-current Wed Jun 4 15:00:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA15648 for current-outgoing; Wed, 4 Jun 1997 15:00:34 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA15273; Wed, 4 Jun 1997 14:55:57 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id HAA18548; Thu, 5 Jun 1997 07:52:34 +1000 Date: Thu, 5 Jun 1997 07:52:34 +1000 From: Bruce Evans Message-Id: <199706042152.HAA18548@godzilla.zeta.org.au> To: gurney_j@resnet.uoregon.edu, se@FreeBSD.ORG Subject: Re: sio driver performance Cc: current@FreeBSD.ORG, straka@inficad.com Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> also, it's a know fact that the 16550's are kinda heavy on overhead >> (not as bad as a parallel port though)... if you want to do many >> ports at full speed you really should invest in a smarter card, >> like a Digiboard/Cyclom/Riscom/Stallion smart board that has larger >> buffers and usually supports mapped memory access... > >Well, the 16550's FIFO will be read a byte a time, and >that means you will be limited to a few MB/s (Bruce Evans >did some testing of ISA port latencies, recently, and >posted his results). This makes some 10 microseconds per >14 bytes (if the receive FIFO was set to 14 bytes, that is). My old ISA/VLB system is significantly faster than my PCI/ISA system for ISA i/o. Not too surprisingly, the BIOS has more ISA knobs to twiddle. I think I have both systems set to 8MHz 1 wait state, but I get access times of 1179 nsec (9+ clocks) for port 0x3F8 on the PCI/ISA system and 978 nsec (7+ clocks) on the ISA/VLB system. For address 0xd4000 on a Cyclades 8Yo board, the access time is 798 nsec (6+ clocks). >A FIFO depth of 8 will reduce the time to read out those >8 bytes to some 5 microseconds. This amounts to 7 milli- >seconds per second (or just below 1%) per port, not taking >the interrupt handler overhead into account ... No, 8 bytes always take at least 8 i/o's to read, and in the current version of the driver they actually take 16+ i/o's to read, because each byte is accompanied by a status byte that has to be read and there are a couple of other status bytes to read. At 1 usec per byte it takes about 20 usec to do the i/o. General (fast)interrupt overhead is approx. 10 usec on a 486/33. The FIFO depth must be at least 4 for the overhead to be no larger than the i/o time. When it is 1 (no FIFO), efficiency suffers by a factor of 4. Increasing the depth above 14 doesn't have much effect on overheads. Bruce