Date: Sat, 23 Nov 2002 08:57:11 -0800 From: "Maksim Yevmenkin" <Maksim.Yevmenkin@cw.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: <vova@sw.ru>, <shizukakudo_99@yahoo.com>, <freebsd-current@FreeBSD.ORG> Subject: RE: Bluetooth questions Message-ID: <45258A4365C6B24A9832BFE224837D552B1266@sjdcex01.int.exodus.net>
next in thread | raw e-mail | index | archive | help
> In message: = <45258A4365C6B24A9832BFE224837D552B1265@sjdcex01.int.exodus.net> > "Maksim Yevmenkin" <Maksim.Yevmenkin@cw.com> writes: > :=20 > : > 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.=20 > : >=20 > : > 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 > : everything is set to 115200, but i think the hardware does=20 > : 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 > OLDCARD on -current? of course :) my code for -current only.=20 > 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. you are right. it is probably 921600 baud as maximal Bluetooth link speed si 723.2 kbit/s. i also do recall someone from CSR (Bluetooth chip manufacturer) said that they have cards with 1.5 mbit UARTs and have no problem at all. another problem here is that UART based cards do not implement flow control, i.e. when RX FIFO is full the card does not assert flow control to remote peer to say "i'm full". it just *assumed* that PC should be fast enough to get data out of RX FIFO before it overflows :( > Uggg. It looks like I gotta find a way to have ISA interrupts work, > even with NEWCARD... :-( looks like it. 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?45258A4365C6B24A9832BFE224837D552B1266>