Date: Sat, 23 Nov 2002 09:09:38 -0800 From: "Maksim Yevmenkin" <Maksim.Yevmenkin@cw.com> To: "Bruce Evans" <bde@zeta.org.au>, "M. Warner Losh" <imp@bsdimp.com> Cc: <vova@sw.ru>, <shizukakudo_99@yahoo.com>, <freebsd-current@FreeBSD.ORG> Subject: RE: Bluetooth questions Message-ID: <45258A4365C6B24A9832BFE224837D552B1267@sjdcex01.int.exodus.net>
next in thread | raw e-mail | index | archive | help
> On Fri, 22 Nov 2002, M. Warner Losh wrote: >=20 > > 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. >=20 > 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. >=20 > 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. >=20 > 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). >=20 > > : 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. >=20 > 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. i do not think so. the card seem to have onboard memory of at least 512 bytes, because it re-assembles baseband packes and send them back to me in 512 bytes chunks. so it seems baseband puts bytes into memory buffer and then card feeds the bytes to PC via UART. i've never seen a "tty buffer overflow" messages. long time ago i wrote TTY driver for Granch serial card (for 4.x) and i'm pretty sure the card was doing 2mbit/s (its max speed) without any problem. BTW -current has driver for it. it is called if_sbni (i think). but if_sbni driver is a network one (from card manufacturer) and a little bit slower then serial one (because of overflow on Ethernet checksum etc.). > > 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. >=20 > 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). it worked for me on -current :) max 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?45258A4365C6B24A9832BFE224837D552B1267>