Date: Sun, 24 Nov 2002 15:54:52 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: Maksim.Yevmenkin@cw.com, <vova@sw.ru>, <shizukakudo_99@yahoo.com>, <freebsd-current@FreeBSD.ORG> Subject: Re: Bluetooth questions Message-ID: <20021124151956.S52130-100000@gamplex.bde.org> In-Reply-To: <20021123.140223.15084544.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Nov 2002, M. Warner Losh wrote:
> In message: <20021123205433.J49198-100000@gamplex.bde.org>
> Bruce Evans <bde@zeta.org.au> writes:
> : 56k is a silly speed to use. Why not use the normal speed of 57600
> : bps or the faster speed of 115200 bps? I haven't got around to updating
> : the 57600 in the example in /etc/rc.serial although this example became
> : bad about 7 years ago just before 56k modems became normal. IIRC, I
> : only had a 14400 bps modem when I wrote the example.
>
> I've used a 56k modem, which doesn't give a sustained speed higher
> than about 56k :-). That's what I ment.
Burst rates can be higher though.
> : For the non-fast interrupt case, part of the problem is that the
> : interrupt handler is not marked MPSAFE although it probably is MPFSAFE,
> : so it has the same latency problems as most other interrupt handlers
> : -- almost everything is blocked by Giant, and Giant can easily be held
> : for 10 msec or so (e.g., in the mii tick code when it is run as a
> : non-MPSAFE timeout). In RELENG_4, non-fast tty interrupts are only
> : blocked by spltty(), so the latency problems are mostly isolated to
> : a few low-quality drivers (e.g., syscons normally busy-waits for
> : several msec in its tty interrupt handler to program LEDs).
>
> I'll have to try that.
I use this, but haven't actually tested the non-fast case. In theory
things should just work the locking requirements for fast interrupt
handlers are stronger than Giant.
Index: sio.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/sio/sio.c,v
retrieving revision 1.382
diff -u -2 -r1.382 sio.c
--- sio.c 11 Oct 2002 20:22:20 -0000 1.382
+++ sio.c 17 Oct 2002 20:18:53 -0000
@@ -1117,5 +1146,6 @@
if (ret) {
ret = BUS_SETUP_INTR(device_get_parent(dev), dev,
- com->irqres, INTR_TYPE_TTY,
+ com->irqres,
+ INTR_TYPE_TTY | INTR_MPSAFE,
siointr, com, &com->cookie);
if (ret == 0)
> : Does the hardware also do something funny with the input fifo size
> : (which would make it non-16550 compatible)? Speeds faster than the
> : nominal speed break things even if the interrupt handler can keep up,
> : by generating more input than fits in buffers in upper layers. Fifos
> : larger than the nominal size may break flow control in related ways.
> : But silo overflows mean problems at the interrupt layer.
>
> Most of the 16650, 16750 and 16850 chips require special care to
> enable the larget fifo, iirc, so that the compatibility problems don't
> happen.
They are enabled by driver flags which should only be used if they help
since they driver doesn't really understand them and at least the original
16650 has broken-as-designed hardware flow control. T he driver doesn't
understand its brokenness and enables it, unlike the Linux driver which
at least used to ignore the possiblility of hardware flow control. The
brokenness is that flow control is invoked when the input fifo trigger
level is reached, so throughput is degraded if the sender actually notices
the flow control in time, and the senders time is wasted by unnecessary
interrupts for flow control.
> You are right about the buffer sizes in the intermeidate
> layers being sized for bursts of 16 bytes, not bursts of, say, 100
> bytes.
Actually, they are sized for bursts related to hz without any knowledge
of the burst size. Setting hz to a large value gives interrupt-level
buffers of size 128 (it would be lower but is clamped to 128, which
more or less corresponds to clamping the timeout period to 1/200 (not
1/hz)). 128 works OK if and only the driver's SWI isn't blocked (by
Giant?) for too long and the burst length is significantly less than
128. Using the default hz gives interrupt-level buffer sizes of 512
at 115200 bps and 256 at 57600 bps so there is more slop for large
fifos.
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?20021124151956.S52130-100000>