Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Aug 2002 20:04:04 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Maksim Yevmenkin <myevmenk@exodus.net>
Cc:        current@FreeBSD.ORG
Subject:   Re: Interrupt vs. polling on -current
Message-ID:  <20020810192039.E16346-100000@gamplex.bde.org>
In-Reply-To: <3D540794.E487F2F4@exodus.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 9 Aug 2002, Maksim Yevmenkin wrote:

> OS: FreeBSD-current DP1 (dmesg attached)
> Laptop: Toshiba Tecra 8100 (docked)
> Hardware: 3Com Bluetooth USB dongle, 3Com Bluetooth PC-CARD
>           Xircom CBT PC-CARD (with 16550A UART)
>
> First of all, irq 11 gets shared between PC-CARD controller,
> USB controller, NIC in docking station (see dmesg). Everything

This configuration should be expected to work poorly at best.

> that i plug into PC-CARD slots also get irq 11 (which is
> normal - i think). Also i have disabled "interrupt harvesting".
>
> My tests are very simple. I plug USB dongle and one PC-CARD
> and try to pump data between them as fast as possible. The
> data blocks sizes are between 63 and 1500 bytes.
>
> The Xircom card just does not work :( I' getting a lot of
> "silo overflow" messages no matter what i try. I checked
> list archives and source - not much look. Is "sio" driver
> totally hopeless?

No, but the 3Com driver apparently is.  The sio driver wants to have
fast interrupts.  It can't have them with the irq is shared, so its
worst-case interrupt latency for a single serial port is increased
from about 50 usec to many msec, depending other interrupt activity
in the system (not limited to that for the shared irq except in some
configurations).  Silo overflows occur at 115200 bps when the latency
is more than about 1.5 msec.

> The 3Com PC-CARD is a little bit better, but after some time
> it also starting to drop bytes.
>
> This morning i change 3Com driver to use polling, and,
> to my extreme surprise it work much, much better now. Also
> the interrupt load (according to top) has reduced to at
> least half. I have not noticed any system slow down. So
> what is up this that? Does that mean that for slow devices
> like serial ports etc. polling is better?

This points to  bug(s) in the 3Com driver.  Perhaps its interrupt
handler just runs for too long to determine that irq11's for the
serial device are not for it.  Running in polled mode decreases
the number of interrupts that it looks at (if there are a lot of
serial interrupts), and prevents the 3Com interrupt handling from
interfering with serial interrupt handling (because timeouts have
lower priority than all other interrupts).

> Does anyone tried
> to use polling in "sio" driver?

Sure.  This was configurable by leaving out the interrupt specification
in the device line.  Now, leaving out the interrupt spec in the hints
line should work for isa devices.  I don't know of any way to configure
it for pccard devices short of editing the source code.  Polling serial
devices gives much the same latency problems/silo overflows as not using
fast interrupts, but worse since the polling interval is limited by default
HZ and the default HZ is too small for it to work except at low serial
speeds (HZ = 100 only permits 8250/16550 UARTs to work at 600/9600 bps,
respectively).  You never want to use polling for serial devices, but
it may be required as a hack if there is no usable irq (this sometimes
happens for isa devices because isa irqs are not shareable).

> I just can't believe that
> FreeBSD on my Pentium-III/600 can't handle lousy 500-700
> interrupts a second from PC-CARD. Can anyone point me
> into right direction, because i'm obviously doing something
> wrong here.

FreeBSD on a 486/33 can handle about 40000 serial interrupts per second
to do one character of i/o per interrupt).  Pessimizations in -current
have only degraded this by a small factor (2?), provided the driver
uses fast interrupts.  Lose another small factor (2?) for normal interrupts
(using normal interrupts only loses a large factor for latency).

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020810192039.E16346-100000>