Date: Sun, 3 Jan 2010 16:13:00 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: freebsd-bluetooth@freebsd.org Subject: Re: obex transfer speeds Message-ID: <1262535180.378790.1755.nullmailer@galant.ukfsn.org> In-Reply-To: <1261078487.624140.2170.nullmailer@galant.ukfsn.org> References: <20091201125054.44a00147@zelz27> <1259694948.961003.27487.nullmailer@galant.ukfsn.org> <1259695873.086896.28523.nullmailer@galant.ukfsn.org> <bb4a86c70912011525n56cf9187wfecd230daa3c9d1e@mail.gmail.com> <1260285672.503038.542.nullmailer@galant.ukfsn.org> <1260905798.329544.2767.nullmailer@galant.ukfsn.org> <bb4a86c70912151440m76313f3el2b44a90ff446b5c8@mail.gmail.com> <1260983092.17657.10.camel@RabbitsDen> <1261078487.624140.2170.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Dec 2009, Iain Hibbert wrote:
> On Wed, 16 Dec 2009, Alexandre "Sunny" Kovalenko wrote:
> > Sent to:
> > * Motorola Razor V3xx ~85 KBytes/sec
> > * Nokia N810 ~120 KBytes/sec
> > * ThinkPad T500 (running Windows) ~150 KBytes/sec
>
> Yes, these are much more realistic figures than mine thanks.. I note that
> the Bluetooth page on wikipedia lists a HTC device that has 2.0 but not
> EDR and I wonder if that is the case for my phone too (HTC Elf). I will do
> some more research next week when I might have some time..
Ok, some more research.. My slowness seems to be a combination of several
issues. To start with, using the same system but with a CSR 2.0+EDR dongle
rather than the inbuilt BCM2045B device I get 40-50KBytes/sec (about 3x
before).
But, capturing the transfer of a 1Mb datafile shows that windows mobile
itself is not very clever at sending RFCOMM flow-control credits in what
is basically a one-sided connection (data is only flowing out). It seems
to have space for about 55 packets in its buffer but doesn't send credits
until it has [just about] run out, sigh. So I get the following scenario:
< ACL data: handle 12 flags 0x02 dlen 135
L2CAP(d): cid 0x0070 len 131 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 8 pf 0 ilen 127 fcs 0x5a
< ACL data: handle 12 flags 0x02 dlen 135
L2CAP(d): cid 0x0070 len 131 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 8 pf 0 ilen 127 fcs 0x5a
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
that repeats for a while, sending, sending..
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
and runs out of steam..
> ACL data: handle 12 flags 0x02 dlen 9
L2CAP(d): cid 0x0041 len 5 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 8 pf 1 ilen 0 fcs 0x9c credits 51
until the credits arrive and we may start sending again.
Doubling the RFCOMM frame size or altering the OBEX mtu made small
differences but not very significant.
Setting up transfers with my NetBSD laptop and obexapp at each end using
different dongles showed that the BCM2045B itself is pretty slow, in that
it never really got much over 20KBytes/sec whereas two CSR 2.0+EDR dongles
managed a solid 60KBytes/sec with the more regular credit flow.
The rates are still less than Sunny so I guess there could also be
improvements to be made in the stack itself, and it would probably be
easier to test if I had more hardware or could compare the same equipment
with a different OS.
iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1262535180.378790.1755.nullmailer>