From owner-freebsd-bluetooth@FreeBSD.ORG Sun Jan 14 02:14:59 2007 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 074D416A40F for ; Sun, 14 Jan 2007 02:14:59 +0000 (UTC) (envelope-from triosoft@triosoft.com.ua) Received: from a64.ic.uz.ua (a64.ic.uz.ua [212.1.100.5]) by mx1.freebsd.org (Postfix) with ESMTP id 7BE3413C441 for ; Sun, 14 Jan 2007 02:14:58 +0000 (UTC) (envelope-from triosoft@triosoft.com.ua) Received: from [127.0.0.1] (helo=webmail.ic.uz.ua) by a64.ic.uz.ua with esmtp (Exim 4.65) (envelope-from ) id 1H5utY-000IXW-U7; Sun, 14 Jan 2007 04:14:53 +0200 Received: from 29-3-124-91.pool.ukrtel.net ([91.124.3.29]) (SquirrelMail authenticated user triosoft@triosoft.com.ua) by webmail.ic.uz.ua with HTTP; Sun, 14 Jan 2007 04:14:52 +0200 (EET) Message-ID: <54256.91.124.3.29.1168740892.squirrel@webmail.ic.uz.ua> In-Reply-To: <45A81220.9010601@savvis.net> 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> <45A57347.4000207@savvis.net> <57864.91.124.5.144.1168549909.squirrel@webmail.ic.uz.ua> <45A81220.9010601@savvis.net> Date: Sun, 14 Jan 2007 04:14:52 +0200 (EET) From: triosoft@triosoft.com.ua To: "Maksim Yevmenkin" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-bluetooth@freebsd.org Subject: Re: is bluetooth 2.0 speeds supported on freebsd? - SOLVED! X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 02:14:59 -0000 -skip- > ok, i just tried to transfer 7 mbytes file from one box to another using > bluetooth 2.0+edr dongles and obexapp. > > i can confirm that throughput is nowhere near bluetooth 2.0+edr > throughput. i basically get around 55 kbytes/sec (around 440 kbit/sec) > which is way too low. > > i do not think that this has anything to do with the dongles or the > stack (because i demonstrated about 2 mbit throughput with lan profile > and ttcp), so it could only be either obexapp itself on openobex library. > That's all in MTU!!! > btw, what tool did you use on ubuntu linux to transfer files over obex? > can you tell it uses openopex library as well? > Some gui app says KDE OBEX client or something similar.. I have linux live cd at work, can't look on it just now. > in the mean time, i'm going to take a look at obexapp and see if i > goofed anywhere. I found out, that the whole problem could be solved if we change OBEX mtu value to something greater, than openobex-1.3.0 OBEX_DEFAULT_MTU = 1024. First of all, I try to change OBEX_DEFAULT_MTU to OBEX_MAXIMUM_MTU in btobex.c in (openobex src), recompile and reinstall opeobex, use obexapp - NO RESULT! same slow speeds. So I decide to patch obexapp to add new option "-m mtu OBEX MTU" - to specify OBEX mtu from command line. And after patching obexapp and make some tests I found, that with OBEX mtu = 65535 speed of file transfer rise significantly! So I make much more tests (results below) and found out optimal value of OBEX mtu = 8192. It is just my opinion based on my NOT WERY CLEAN TESTS. not wery clean, because i use stopwatch to measure time of file transfers and I cannot guarantee totally same env for every test. But I think totally same env isn't so important, as you see from test results. So here is tests: First of all I test time for getting file (9485856 bytes - the same file in all test) from phone (Nokia N73) with obexapp -a n73 -C FTRN -m XXXXX when phone was about 20 cm far from bluetooth dongle. Then I move phone for about 6 m with semi-clean air between phone and dongle, and then I took phone to other room (wall + some furniture between phone and dongle) about 10 m far from dongle. I use "get filename" command to get file. Results: ======TEST RESULTS START======= mtu time in min.sec 20 cm 65535 - 1.09 32768 - 1.17 16384 - 1.19 8192 - 1.24 4096 - 1.47 2048 - 2.34 1024 - 3.55 600 cm - semi clean air 65535 - 1.22 8192 - 1.24 about 10 m with one wall and some furniture 65535 - 1.30 8192 - 1.39 2048 - 2.42 ======TEST RESULTS STOP======== So you can see THE VISIBLE DIFFERENCE :o) And you can see, why I choose 8192 as an optimal mtu. So all LOW SPEED-problem is due to small mtu and great OBEX overheat with it. But my colleague talk to me, and said, that it is stupid idea, to adjust mtu from user app. After some hours of debates, I try to hardcode 8192 into openobex. And only when I change OBEX_DEFAULT_MTU to 8192 (in opex_const.h) and recompile and reinstall openobex libs I get nice results from UNPATCHED obexapp. But I don't think, that we can simply change OBEX_DEFAULT_MTU value for whole lib, because there is more than just bluetooth transports around in lib, which can be harmed with such mtu. So I think that for now it is nice idea to set reasonable (or desirable mtu) from obexapp. Comments or better solutions are wellcome! Patch against obexapp goes below... ===OBEXAPP PATCH START===== diff -ruN obexapp.orig/client.c obexapp/client.c --- obexapp.orig/client.c Wed Dec 29 23:49:05 2004 +++ obexapp/client.c Sun Jan 14 04:05:07 2007 @@ -97,6 +97,11 @@ char s1[PATH_MAX], s2[PATH_MAX], *p1, *p2; int done, error; + if (OBEX_SetTransportMTU(handle, context->mtu, context->mtu) < 0) { + syslog(LOG_ERR, "%s(): OBEX_SetTransportMTU failed", __func__); + return (-1); + } + if (OBEX_TransportConnect(handle, (void *) 1, 0) < 0) { syslog(LOG_ERR, "%s(): OBEX_TransportConnect failed", __func__); return (-1); @@ -514,6 +519,11 @@ } /* CONNECT */ + if (OBEX_SetTransportMTU(handle, context->mtu, context->mtu) < 0) { + syslog(LOG_ERR, "%s(): OBEX_SetTransportMTU failed", __func__); + return (-1); + } + if (OBEX_TransportConnect(handle, (void *) 1, 0) < 0) { fprintf(stderr, "OBEX_TransportConnect failed\n"); return (-1); diff -ruN obexapp.orig/main.c obexapp/main.c --- obexapp.orig/main.c Fri Dec 24 01:09:48 2004 +++ obexapp/main.c Sun Jan 14 04:05:07 2007 @@ -94,6 +94,7 @@ context.addr.rfcomm_family = AF_BLUETOOTH; context.tfd = context.sfd = -1; context.detach = 1; + context.mtu = OBEX_MAXIMUM_MTU; context.ls_size = OBEXAPP_BUFFER_SIZE; if ((context.ls = (char *) malloc(context.ls_size)) == NULL) { @@ -145,7 +146,7 @@ /* Process command line options */ service = noninteractive = 0; - while ((n = getopt(argc, argv, "a:A:cC:dDfhnr:Ssu:")) != -1) { + while ((n = getopt(argc, argv, "a:A:cC:dDfhm:nr:Ssu:")) != -1) { switch (n) { case 'a': if (!bt_aton(optarg, &context.addr.rfcomm_bdaddr)) { @@ -210,6 +211,15 @@ context.fbs = 1; break; + case 'm': /* MTU */ + + context.mtu = strtoul(optarg, &ep, 10); + + if((*ep || context.mtu < OBEX_MINIMUM_MTU) || \ + (context.mtu > OBEX_MAXIMUM_MTU)) + errx(1, "%s: %s", optarg, "invalid OBEX MTU"); + break; + case 'n': /* non-interactive client mode */ if (context.server) usage(basename(argv[0])); @@ -354,6 +364,7 @@ "-D use stdin/stdout instead of socket\n" \ "-f use Folder Browsing Service\n" \ "-h display this message\n" \ +"-m mtu set OBEX mtu\n" \ "-n non-interactive mode (client mode)\n" \ "-r path set path to root directory\n" \ "-s act as server\n" \ diff -ruN obexapp.orig/obexapp.h obexapp/obexapp.h --- obexapp.orig/obexapp.h Wed Dec 29 23:49:05 2004 +++ obexapp/obexapp.h Sun Jan 14 04:05:07 2007 @@ -108,6 +108,9 @@ /* stream file descriptor and buffer */ int sfd; char *sbuffer; + + /* OBEX MTU */ + int mtu; }; typedef struct context context_t; typedef struct context * context_p; ===OBEXAPP PATCH STOP====== It brings up OBEX mtu just to obex_client. For server it is to be done later... >> And one more question, I hack a bit >> src/usr.sbin/bluetooth/hccontrol/util.c to fully dump and describe all 8 >> bytes of features. Is it worthy to post patches here? > > yes OOps... forot them at work... I post them little later... Comments, advices? -- AVR39-RIPE