Same Old Speed Issues

Hello Guys,

You'll have to forgive me, I've posted a copy of this mail to both the users and developers list in the hope that I might widen the audience a little bit and hopefully find a solution to this problem as its been causing me problems for quite some time, I hope you don't mind.

The crux of the issue is that I'm getting very slow OBEX transmit speeds, despite the fact that all the conditions seems to be correct for me to take advantage of the full Bluetooth 2 + EDR specification. I'll try my best to help explain all the details and hopefully you'll have some ideas on diagnosing or solving the problems.

I'm running a USB dongle from Ezurio which is based on a CSR chipset, running Bluetooth version 2.0 with EDR capabilities. more details on the dongle can be found on thier site. http://www.ezurio.co.uk/products/highspeedusbadaptor/

I'm running this on a Debian based system, which is running kernel version 2.6.23 and has Bluez version 3.24 which has been installed from a package on the apt-get service.

At the moment I've tried using both ussp-push and open-obex push clients to transfer the file, both giving me the same results. I'm achieving roughly 25Kbytes/s transfer speed both up and down. I've tried running these same dongles from my Windows PC and achieve well over 100kBytes/s. (This is transmitting to a Sony k850i handset which is v2.0 + EDR). This would lead me to believe its not an issue with the Dongle, more likely something with my Linux configuration

The output from hciconfig -a look as follows, I'm unable to see anything unexpected in it:

hci0: Type: USB BD Address: 00:80:98:E6:38:BD ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING PSCAN ISCAN RX bytes:242063 acl:5074 sco:0 events:16608 errors:0 TX bytes:5053795 acl:24234 sco:0 commands:146 errors:0 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: MASTER Name: 'Hello' Class: 0x080100 Service Classes: Capturing Device Class: Computer, Uncategorized HCI Ver: 2.0 (0x3) HCI Rev: 0xbf4 LMP Ver: 2.0 (0x3) LMP Subver: 0xbf4 Manufacturer: Cambridge Silicon Radio (10)

And likewise when looking at the features for the chip, it lists the EDR support as we would expect.

        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80                <3-slot packets> <5-slot packets> <encryption> <slot offset>                 <timing accuracy> <role switch> <hold mode> <sniff mode>                 <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>                 <HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>                 <power control> <transparent SCO> <broadcast encrypt>                 <EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan>                 <interlaced iscan> <interlaced pscan> <inquiry with RSSI>                 <extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slave>                 <AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL>                 <AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps>                 <EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended features>

This slow speed has been plaguing me for a long time and I've never been able to find anything which looks out of place, regardless of the different kernel and blues editions I've tried.

Can anyone provide any advice? if you need any more information at all them please do let me know.

Thanks for your time,

Robert
_________________________________________________________________
Get Hotmail on your mobile, text MSN to 63463!
http://mobile.uk.msn.com/pc/mail.aspx

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Have you tried changing the OBEX block size - try forcing the minimum size to 64kB-1?

Cheers,
Tim

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hello Tim,

Thanks for getting back me on this. I've not tried changing the block size at all, I would love to give that a go. Would you mind giving me a little advice on how to do so? I had a quick google around but couldn't really find anything related to obex block sizes.

As a little addition to the information I posted yesterday, I've done some more testing this morning. I built a system on different architecture and using a slackware linux instead of debian and still had the same issues. I also went out and bought myself a totally different dongle from a different manufacturer which also has this slow transmit speed, so I can definitely confirm this doesn't appear to be a hardware or OS related issue, I'm guessing something config related.

If you wouldn't mind giving me a little advice on how to change that block size I would love to give that a shot.

Thanks mate for your time,

Rob

_________________________________________________________________
Telly addicts unite!
http://www.searchgamesbox.com/tvtown.shtml

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hello Guys,

I've been playing around with this again today, looking into ALC MTU's and things like that but really can't find any resources to suggest why I might be getting such poor speeds, I thought it would be a plug-and-play kinds of affair.

I also made an effort to try a couple of other kernel versions, just in case, but they all gave the same results as 2.6.23.

Thanks for any further advice guys. Is it worth me giving you some HCI_DUMP information? Is that likely to hold any clues as to what's going wrong?

Cheers,

Rob

_________________________________________________________________
Share what Santa brought you
https://www.mycooluncool.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Good morning,

Another update on my progress with the problem. This morning I had two new version 2.0 + EDR dongles arrive in the post, both from different manufacturer and both listed on the compatibility list for bluez.

I've run some tests this morning on these other two dongles and receive the exact same problem, still not getting anything over 25kBytes/s.

I'm running out of different tests to run, I've tried different dongles, system boards, linux builds, kernel versions, bluez versions and every single one keep presenting the same problems, Am I missing something?

Thanks guys, I would really appreciate any ideas you might have.

Rob

From: [email protected]: [email protected]: Mon, 21 Jan 2008 16:11:14 +0000Subject: Re: [Bluez-devel] Same Old Speed Issues

Hello Guys,

I've been playing around with this again today, looking into ALC MTU's and things like that but really can't find any resources to suggest why I might be getting such poor speeds, I thought it would be a plug-and-play kinds of affair.

I also made an effort to try a couple of other kernel versions, just in case, but they all gave the same results as 2.6.23.

Thanks for any further advice guys. Is it worth me giving you some HCI_DUMP information? Is that likely to hold any clues as to what's going wrong?

Cheers,

Rob

Everything in one place. All new Windows Live!
_________________________________________________________________
Share what Santa brought you
https://www.mycooluncool.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Afternoon Guys,

I know that you're probably getting tired of hearing about this problem but thought I would post some more information in the hope that it might shed some light on the situation and hopefully solve the problem. I just wanted to get your opinion on the HCI dump information which gets output when a file is transferred.

It generally seems to be the following repeated continuously throughout the transfer:

< ACL data: handle 42 flags 0x02 dlen 25 L2CAP(d): cid 0x004f len 21 [psm 3] RFCOMM(d): UIH: cr 1 dlci 12 pf 0 ilen 17 fcs 0x4f > HCI Event: Number of Completed Packets (0x13) plen 5> HCI Event: Number of Completed Packets (0x13) plen 5> HCI Event: Number of Completed Packets (0x13) plen 5> ACL data: handle 42 flags 0x02 dlen 12 L2CAP(d): cid 0x0040 len 8 [psm 3] RFCOMM(d): UIH: cr 0 dlci 12 pf 1 ilen 3 fcs 0x89 credits 2< ACL data: handle 42 flags 0x02 dlen 310< ACL data: handle 42 flags 0x01 dlen 310< ACL data: handle 42 flags 0x01 dlen 310< ACL data: handle 42 flags 0x01 dlen 86 L2CAP(d): cid 0x004f len 1012 [psm 3] RFCOMM(d): UIH: cr 1 dlci 12 pf 0 ilen 1007 fcs 0x4f
Does that look normal to you guys are should it be looking any different? I know this is a bit of a tedious thread but I really would appreciate some help solving this as it seems to be driving me a little crazy, Even if you can point me in the direction of a dongle you are using which you are SURE works at full speed, just so I can test it out.

Thanks guys,

Rob

From: [email protected]: [email protected]: Fri, 25 Jan 2008 10:28:36 +0000Subject: Re: [Bluez-devel] Same Old Speed Issues

Good morning, Another update on my progress with the problem. This morning I had two new version 2.0 + EDR dongles arrive in the post, both from different manufacturer and both listed on the compatibility list for bluez. I've run some tests this morning on these other two dongles and receive the exact same problem, still not getting anything over 25kBytes/s. I'm running out of different tests to run, I've tried different dongles, system boards, linux builds, kernel versions, bluez versions and every single one keep presenting the same problems, Am I missing something? Thanks guys, I would really appreciate any ideas you might have. Rob

From: [email protected]: [email protected]: Mon, 21 Jan 2008 16:11:14 +0000Subject: Re: [Bluez-devel] Same Old Speed Issues

Hello Guys,

I've been playing around with this again today, looking into ALC MTU's and things like that but really can't find any resources to suggest why I might be getting such poor speeds, I thought it would be a plug-and-play kinds of affair.

I also made an effort to try a couple of other kernel versions, just in case, but they all gave the same results as 2.6.23.

Thanks for any further advice guys. Is it worth me giving you some HCI_DUMP information? Is that likely to hold any clues as to what's going wrong?

Cheers,

Rob

Everything in one place. All new Windows Live!

Everything in one place. All new Windows Live!
_________________________________________________________________
Free games, great prizes - get gaming at Gamesbox.
http://www.searchgamesbox.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Johan/Fredric,

Here is the patch which fixes the "supported features" in AG's SDP record.

Let me know if anything needs to be changed.

Thanks,
Alok.

Index: audio/headset.h
===================================================================
RCS file: /cvsroot/bluez/utils/audio/headset.h,v
retrieving revision 1.35

diff -u -5 -p -r1.35 headset.h
@@ -45,11 +45,11 @@ typedef void (*headset_stream_cb_t) (str
 struct headset *headset_init(struct device *dev, sdp_record_t *record,
 				uint16_t svc);
 
 void headset_free(struct device *dev);
 
-int headset_config_init(GKeyFile *config);
+uint16_t headset_config_init(GKeyFile *config);
 
 void headset_update(struct device *dev, sdp_record_t *record, uint16_t svc);
 
 unsigned int headset_request_stream(struct device *dev, headset_stream_cb_t cb,
 					void *user_data);

Index: audio/headset.c
===================================================================
RCS file: /cvsroot/bluez/utils/audio/headset.c,v
retrieving revision 1.160

diff -u -5 -p -r1.160 headset.c
@@ -73,11 +73,11 @@
 #define AG_FEATURE_REJECT_A_CALL                 0x0020
 #define AG_FEATURE_ENHANCES_CALL_STATUS          0x0040
 #define AG_FEATURE_ENHANCES_CALL_CONTROL         0x0080
 #define AG_FEATURE_EXTENDED_ERROR_RESULT_CODES   0x0100
 /*Audio Gateway features.Default is In-band Ringtone*/
-static unsigned int ag_features;
+static uint32_t ag_features = 0;
 static gboolean sco_hci = TRUE;
 
 static char *str_state[] = {
 	"HEADSET_STATE_DISCONNECTED",
 	"HEADSET_STATE_CONNECT_IN_PROGRESS",

@@ -1672,19 +1672,19 @@ register_iface:
 	}
 
 	return hs;
 }
 
-int headset_config_init(GKeyFile *config)
+uint16_t headset_config_init(GKeyFile *config)
 {
 	GError *err = NULL;
 	gboolean value;
 	char *str;
 
 	/* Use the default values if there is no config file */
 	if (config == NULL)
-		return 0;
+		goto done;
 
 	str = g_key_file_get_string(config, "General", "SCORouting",
 					&err);
 	if (err) {
 		debug("audio.conf: %s", err->message);

@@ -1778,12 +1778,12 @@ int headset_config_init(GKeyFile *config
 		debug("audio.conf: %s", err->message);
 		g_error_free(err);
 		err = NULL;
 	} else if (value)
 		ag_features |= AG_FEATURE_EXTENDED_ERROR_RESULT_CODES;
-
-	return 0;
+done:
+	return (uint16_t) ag_features & 0xf;
 }
 
 void headset_free(struct device *dev)
 {
 	struct headset *hs = dev->headset;

Index: audio/manager.c
===================================================================
RCS file: /cvsroot/bluez/utils/audio/manager.c,v
retrieving revision 1.86

diff -u -5 -p -r1.86 manager.c
@@ -1224,19 +1224,18 @@ static int hsp_ag_record(sdp_buf_t *buf,
 	sdp_list_free(record.pattern, free);
 
 	return ret;
 }
 
-static int hfp_ag_record(sdp_buf_t *buf, uint8_t ch)
+static int hfp_ag_record(sdp_buf_t *buf, uint8_t ch, uint16_t feat)
 {
 	sdp_list_t *svclass_id, *pfseq, *apseq, *root;
 	uuid_t root_uuid, svclass_uuid, ga_svclass_uuid;
 	uuid_t l2cap_uuid, rfcomm_uuid;
 	sdp_profile_desc_t profile;
 	sdp_list_t *aproto, *proto[2];
 	sdp_record_t record;
-	uint16_t u16 = 0x0009;
 	sdp_data_t *channel, *features;
 	uint8_t netid = 0x01;
 	sdp_data_t *network = sdp_data_alloc(SDP_UINT8, &netid);
 	int ret;
 

@@ -1265,11 +1264,11 @@ static int hfp_ag_record(sdp_buf_t *buf,
 	proto[1] = sdp_list_append(0, &rfcomm_uuid);
 	channel = sdp_data_alloc(SDP_UINT8, &ch);
 	proto[1] = sdp_list_append(proto[1], channel);
 	apseq = sdp_list_append(apseq, proto[1]);
 
-	features = sdp_data_alloc(SDP_UINT16, &u16);
+	features = sdp_data_alloc(SDP_UINT16, &feat);
 	sdp_attr_add(&record, SDP_ATTR_SUPPORTED_FEATURES, features);
 
 	aproto = sdp_list_append(0, apseq);
 	sdp_set_access_protos(&record, aproto);
 

@@ -1539,10 +1538,11 @@ static int headset_server_init(DBusConne
 {
 	uint8_t chan = DEFAULT_HS_AG_CHANNEL;
 	sdp_buf_t buf;
 	gboolean no_hfp = FALSE;
 	GError *err = NULL;
+	uint16_t feat;
 
 	if (!(enabled.headset || enabled.gateway))
 		return 0;
 
 	hs_server = server_socket(&chan);

@@ -1583,11 +1583,13 @@ static int headset_server_init(DBusConne
 
 	hf_server = server_socket(&chan);
 	if (!hf_server)
 		return -1;
 
-	if (hfp_ag_record(&buf, chan) < 0) {
+	feat = headset_config_init(config);
+
+	if (hfp_ag_record(&buf, chan, feat) < 0) {
 		error("Unable to allocate new service record");
 		return -1;
 	}
 
 	hf_record_id = add_service_record(conn, &buf);

@@ -1683,13 +1685,10 @@ int audio_init(DBusConnection *conn, GKe
 		error("D-Bus failed to register %s path", AUDIO_MANAGER_PATH);
 		goto failed;
 	}
 
 	if (enabled.headset) {
-		if (headset_config_init(config) < 0)
-			goto failed;
-
 		if (headset_server_init(conn, config) < 0)
 			goto failed;
 	}
 
 	if (enabled.sink) {

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hello Guys,

What is the playability of this being a compatibility / driver issue? I noticed on the compatibility list some of the devices were listed as 'works but slow'.If this is a Driver issue what is likely to be the best way to approach it? can the driver be modified? or is it something we should be speaking to the manufacturer about?

Rob

_________________________________________________________________
Get Hotmail on your mobile, text MSN to 63463!
http://mobile.uk.msn.com/pc/mail.aspx

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel