From owner-freebsd-current Thu May 28 19:44:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA29577 for freebsd-current-outgoing; Thu, 28 May 1998 19:44:20 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA29558 for ; Thu, 28 May 1998 19:44:14 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id MAA26085; Fri, 29 May 1998 12:44:07 +1000 Date: Fri, 29 May 1998 12:44:07 +1000 From: Bruce Evans Message-Id: <199805290244.MAA26085@godzilla.zeta.org.au> To: bde@zeta.org.au, jak@cetlink.net Subject: Re: sio0 flag 0x20000 Cc: freebsd-current@FreeBSD.ORG, joelh@gnu.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>On Startech16650s, it should improve CTS flow control and unimprove RTS >>flow control (hardware RTS flow control is broken as designed on at >>least ST16550s). > >"Broken," or unoptimized? (rhetorical question) Pessimized by design. IIRC, it invokes flow control when the fifo trigger level is reached. The fifo trigger level will always be reached while input is streaming in. Sometimes, the external device will notice the flow control and stop sending for a microsecond or two that it takes to begin servicing the interrupt and read a byte or two from the fifo. Every time, the external device will have to do extra work to notice the flow control changes (typically, 2 extra interrupts per change). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message