Date: Sat, 23 Nov 2002 21:39:54 +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: <20021123205433.J49198-100000@gamplex.bde.org> In-Reply-To: <20021122.223559.37439667.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Nov 2002, M. Warner Losh wrote: > In message: <45258A4365C6B24A9832BFE224837D552B1265@sjdcex01.int.exodus.net> > "Maksim Yevmenkin" <Maksim.Yevmenkin@cw.com> writes: > : > : > In message: <45258A4365C6B24A9832BFE224837D552B1264@sjdcex01.int.exodus.net> > : > "Maksim Yevmenkin" <Maksim.Yevmenkin@cw.com> writes: > : > : I see a lot of "silo overflow" errors under moderate load. > : > : As a result bytes get dropped on the floor. The Bluetooth > : > : spec defines extremely simple serial protocol (H4). It simply > : > : cannot tolerate UARTs that drop bytes. If at least one byte > : > : gets dropped the entire HCI frame is lost. If HCI frame gets > : > : dropped then "out of sync" condition exist and all bets are > : > : off. The only way to get back "in sync" is to send Reset to > : > : the device. After Reset device goes into standby state and > : > : all operational state is lost. > : > > : > OK. That makes sense. Part of the problem even with even fast > : > interrupt handlers is that interrupts are masked for way way too much > : > code in -current, as compared to -stable. What baud rate are you > : > running at? I'm running at 56k, which isn't the full datarate for > : > 115200 baud that could be used. Even with a fast interrupt, you'd get > : > SIO overflows in current, at least according to some reports. 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 haven't noticed many problems with the fast interrupt handler case. External interrupt latency is certainly pessimized by 500% or so, and non-i/o internal overheads are pessimized by 200% or so, but i/o overheads are still dominant on anything faster than a 486 or maybe a Pentium-1. 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). > : everything is set to 115200, but i think the hardware does > : something funny with the divisor and internal rate is much > : higher. with OLDCARD i managed to run Xircom card with fast > : interrupts and acually got about 50 KBytes/sec. USB devices > : give me about 60KBytes/sec. 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. > OLDCARD on -current? > > Chances are there's either an 8x the normal or 'custom'. With the > settings on current, Let's assume a 8x is 921600 baud. That means > that each bit is 1us, so each byte is 10us (1 start + 8 bits + 1 > stop). The FIFO is 16 bytes (unless this part is a 16650 or something > like that), which is set to go off at MEDH, which is 8 bytes from > empty. This puts the upper bound of interrupt latency at 80us or so. This should work for the fast interrupt case even on a 486/33, since it's the same as for 1x with an unbuffered UART which worked fine in FreeBSD-1.x (for 2 ports 4 with 4 data streams and 4 * 11520 interrupts/second). However, the pessimizations since FreeBSD-1.x make probably make this marginal at best even with 1 port, and DMA can easily block ISA accesses and increase latency to much more than 80 usec (160-200 usec seems to be a normal upper bound on PCI latency when PCI timers ares slightly misconfigured). 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?20021123205433.J49198-100000>