From owner-freebsd-hackers Sat Jun 28 06:56:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA20298 for hackers-outgoing; Sat, 28 Jun 1997 06:56:21 -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 GAA20293 for ; Sat, 28 Jun 1997 06:56:17 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA30041; Sat, 28 Jun 1997 23:53:27 +1000 Date: Sat, 28 Jun 1997 23:53:27 +1000 From: Bruce Evans Message-Id: <199706281353.XAA30041@godzilla.zeta.org.au> To: bde@zeta.org.au, Shimon@i-Connect.Net Subject: Re: Clists limited to 1024 bytes? Cc: bmcgover@cisco.com, hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> You don't want to do this. At 19200 bps, an 8K buffer takes more than >> 4 seconds to fill. A latency of 4 seconds is normally about 400 times >> too large. At such a low speed, there is normally nothing better than >> delivering input in tiny bursts of 19-20 characters every 10 msec. > >Except with heavy PPP loads. Right? For ppp, it is better to deliver input in full packets a few microseconds after each packet becomes complete. The sio and cy drivers more or less do this (they delivers input every 10 msec and a few microseconds after a PPP_FLAG character is received). To match the throughput of these drivers, the hardware must support interrupting at least as often as these drivers would deliver a packet. The cy hardware has support for interrupting on every PPP_FLAG (and some other) characters, but it is not used by default because the extra interrupts cost more and the latency was only reduced by a few hundred microseconds (at most the time to fill the input fifo). Perhaps this option should be used at low speeds. The interrupt-on-special-character feature would be essential for devices with larger fifos (unless the device supports ppp directly). Anyway, 19200 bps is not a heavy load unless there are a lot of active ports. With 32 active 16550 ports it would be fairly heavy, but still gives less than 6% of the throughput of a single 10Mb/s ethernet. Bruce