Date: Wed, 10 Jan 2007 15:14:15 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: "Alexander V. Ribchansky" <triosoft@triosoft.com.ua> Cc: freebsd-bluetooth@freebsd.org Subject: Re: is bluetooth 2.0 speeds supported on freebsd? Message-ID: <45A57347.4000207@savvis.net> In-Reply-To: <1168465461.328656.2681.nullmailer@galant.ukfsn.org> References: <45A3BAAB.4040903@zk.informjust.ua> <45A3D66C.2050605@savvis.net> <49327.91.124.7.194.1168371717.squirrel@webmail.ic.uz.ua> <45A3F31D.2060709@savvis.net> <1168378526.559195.4307.nullmailer@galant.ukfsn.org> <45A4AF8F.90106@triosoft.com.ua> <1168465461.328656.2681.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain Hibbert wrote: > On Wed, 10 Jan 2007, Alexander V. Ribchansky wrote: > >> Iain Hibbert ?????: >>> ptype: [0xcc18] DM1 DH1 DM3 DH3 DM5 DH5 2-DH1 3-DH1 2-DH3 3-DH3 2-DH5 3-DH5 >> I'm a very-very newbie in bluetooth, but if the whole problem is to >> properly detect adapter capabilities and to properly config frame mask >> if adapter supports EDR, could someone tell me a place in src, where I >> should apply WHERRY DIRTY HACK to insist that adapter support EDR >> frames? just to test if it work with 2.0 adapter. Or I miss something, >> reading this thread? > > You need to adjust the packet types that are allowed - look at > sys/netgraph/bluetooth/hci/ng_hci_ulpi.c and search for CREATE_CON to see > where the connection is made. Just a few lines down hardwire > req->cp.pkt_type=0xcc18 which should enable all the packet types as > above. > > To make it work properly, you would have to interpret the other packet > types from the mask. actually, it appears that nothing is required to be done at all. i got my self a couple of bluetooth 2.0+edr dongles from bestbuy, specifically Jan 10 14:21:40 beetle kernel: ubt0: <Kensington Bluetooth EDR Dongle, class 224/1, rev 2.00/0.00, addr 2> on uhub2 Jan 10 14:21:40 beetle kernel: ubt0: Kensington Bluetooth EDR Dongle, rev 2.00/0.00, addr 2 Jan 10 14:21:40 beetle kernel: ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 Jan 10 14:21:40 beetle kernel: ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 and Jan 10 14:21:46 beetle kernel: ubt1: <Broadcom Corp BCM92045DG-Flash_UHE, class 224/1, rev 2.00/1.00, addr 3> on uhub6 Jan 10 14:21:46 beetle kernel: ubt1: Broadcom Corp BCM92045DG-Flash_UHE, rev 2.00/1.00, addr 3 Jan 10 14:21:46 beetle kernel: ubt1: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 Jan 10 14:21:46 beetle kernel: ubt1: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 and connected them to two different freebsd boxes, specifically FreeBSD beetle.savvis.net 7.0-CURRENT FreeBSD 7.0-CURRENT #79: Tue Nov 21 17:21:46 PST 2006 max@beetle.digisle.com:/usr/obj/usr/src/sys/GENERIC i386 and FreeBSD peahi.savvis.ad.savvis.net 7.0-CURRENT FreeBSD 7.0-CURRENT #14: Tue Nov 21 10:57:25 PST 2006 max@peahi.savvis.ad.savvis.net:/usr/obj/usr/src/sys/GENERIC sparc64 both boxes are sitting about two meters apart in my office. i used ttcp (ports/benchmarks/ttcp) as basic tool to measure throughput. both machines connected using bluetooth lan profile (i.e. ppp over rfcomm link) ppp config on server: rfcomm-server: #enable force-scripts set timeout 0 set lqrperiod 10 set ifaddr 192.168.1.2 192.168.1.1 255.255.255.255 enable lqr accept lqr disable pap deny pap disable chap deny chap accept dns ppp config on client rfcomm-client: set dial set timeout 0 set ifaddr 192.168.1.1 192.168.1.2 255.255.255.255 accept dns now results receiver side: peahi% ttcp -r -s -f m ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket ttcp-r: accept from 192.168.1.2 ttcp-r: 16777216 bytes in 72.29 real seconds = 1.77 Mbit/sec +++ ttcp-r: 11684 I/O calls, msec/call = 6.34, calls/sec = 161.63 ttcp-r: 0.1user 2.6sys 1:12real 3% 166i+1416d 1860maxrss 0+0pf 11682+1039csw sender side: beetle# ttcp -t -s 192.168.1.1 ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> 192.168.1.1 ttcp-t: socket ttcp-t: connect ttcp-t: 16777216 bytes in 72.28 real seconds = 226.66 KB/sec +++ ttcp-t: 2048 I/O calls, msec/call = 36.14, calls/sec = 28.33 ttcp-t: 0.0user 0.2sys 1:12real 0% 1i+341d 424maxrss 0+0pf 7774+17csw as you can see i got close to 2 Mbit/sec throughput (receiver reports in Mbit/sec and sender reports in Kbytes/sec). numbers look consistent on both sides. in theory bluetooth 2.0+edr can give you up to 3 Mbit/sec (please correct me if i wrong here), but in real life you unlikely to see this because of protocol header overhead. in this case its protocol stack looks something like tcp -> ip -> ppp -> rfcomm -> l2cap bottom line: it looks like bluetooth 2.0+edr dongles will talk high speed without stack doing anything at all. i'm not sure why do you see low transfer speed, but perhaps it has something to do with obex? thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45A57347.4000207>