Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Jan 2007 04:14:52 +0200 (EET)
From:      triosoft@triosoft.com.ua
To:        "Maksim Yevmenkin" <maksim.yevmenkin@savvis.net>
Cc:        freebsd-bluetooth@freebsd.org
Subject:   Re: is bluetooth 2.0 speeds supported on freebsd? - SOLVED!
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>

next in thread | previous in thread | raw e-mail | index | archive | help
-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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54256.91.124.3.29.1168740892.squirrel>