Hi all,
I've lived with slow transfer speeds long enough. Ever since I purchased an ASUS Bluetooth 2.0+EDR USB adapter it has always taken *minutes* instead of *seconds* to transfer files from my cell phone to my computer and vice versa.
Fedora 8, latest updates. Nokia N95-1, latest firmware.
Both are Bluetooth 2.0+EDR devices.
It took *40 seconds* to transfer a 1 megabyte picture. I timed this with 'watch -n 1 date' for grins, so I can't give you nanosecond numbers, but even a rough estimate shows that transfer speeds are *abysmal* and need to be addressed. Ideally it should be taking less than 10 seconds to transfer the same image file on a true 2.0+EDR setup. I have two different computers with two of the same Asus adapter. Same speeds.
I saw someone fixed this by forcing larger MTUs. http://lists.freebsd.org/pipermail/...ary/000847.html http://lists.freebsd.org/pipermail/freebsd-bluetooth/2007-January/000847.html
Before modifying the OpenOBEX sources, I posted a message on their board, but I haven't heard anything yet. Does anyone have any experience with this?
I have tried the fedora-list without an answer. Also, the OpenOBEX developers are silent on this. Is this because no one has a 2.0 adapter and 2.0 device?
Thanks, Mike
On Tue, 2008-04-01 at 11:11 -0500, Mike Cronenworth wrote:
Hi all,
I've lived with slow transfer speeds long enough. Ever since I purchased an ASUS Bluetooth 2.0+EDR USB adapter it has always taken *minutes* instead of *seconds* to transfer files from my cell phone to my computer and vice versa.
Fedora 8, latest updates. Nokia N95-1, latest firmware.
Both are Bluetooth 2.0+EDR devices.
It took *40 seconds* to transfer a 1 megabyte picture. I timed this with 'watch -n 1 date' for grins, so I can't give you nanosecond numbers, but even a rough estimate shows that transfer speeds are *abysmal* and need to be addressed. Ideally it should be taking less than 10 seconds to transfer the same image file on a true 2.0+EDR setup. I have two different computers with two of the same Asus adapter. Same speeds.
That certainly doesn't rule out a bug in the dongle's firmware for example.
I saw someone fixed this by forcing larger MTUs. http://lists.freebsd.org/pipermail/...ary/000847.html http://lists.freebsd.org/pipermail/freebsd-bluetooth/2007-January/000847.html
Before modifying the OpenOBEX sources, I posted a message on their board, but I haven't heard anything yet. Does anyone have any experience with this?
OpenObex upstream is pretty much dead(-ish). Let's call it maintenance mode.
I have tried the fedora-list without an answer. Also, the OpenOBEX developers are silent on this. Is this because no one has a 2.0 adapter and 2.0 device?
Probably not, one of the upstream for OpenObex is Marcel Holtmann, and he certainly has more Bluetooth 2.0 devices than you or I.
Test the patch, tell us if it works, and mail the bluez-users list about it. There's also ACL and SCO MTUs to take in consideration, and I would guess the bug is more likely to be there (in the kernel, in the firmware of your dongle, or the firmware of your phone) than solely in OpenObex.
Cheers
-------- Original Message -------- Subject: Re:bluetooth 2.0 is extremely slow From: Bastien Nocera bnocera@redhat.com To: mike@cchtml.com, Development discussions related to Fedora fedora-devel-list@redhat.com Date: 04/01/2008 11:28 AM
On Tue, 2008-04-01 at 11:11 -0500, Mike Cronenworth wrote:
Hi all,
I've lived with slow transfer speeds long enough. Ever since I purchased an ASUS Bluetooth 2.0+EDR USB adapter it has always taken *minutes* instead of *seconds* to transfer files from my cell phone to my computer and vice versa.
Fedora 8, latest updates. Nokia N95-1, latest firmware.
Both are Bluetooth 2.0+EDR devices.
It took *40 seconds* to transfer a 1 megabyte picture. I timed this with 'watch -n 1 date' for grins, so I can't give you nanosecond numbers, but even a rough estimate shows that transfer speeds are *abysmal* and need to be addressed. Ideally it should be taking less than 10 seconds to transfer the same image file on a true 2.0+EDR setup. I have two different computers with two of the same Asus adapter. Same speeds.
That certainly doesn't rule out a bug in the dongle's firmware for example.
I punched myself into loading Windows XP (latest updates, latest drivers) and the same file (or any 1 meg file) transfers in *10 seconds*. A factor of four on speed improvement. There's nothing wrong with the firmware.
I saw someone fixed this by forcing larger MTUs. http://lists.freebsd.org/pipermail/...ary/000847.html http://lists.freebsd.org/pipermail/freebsd-bluetooth/2007-January/000847.html
Before modifying the OpenOBEX sources, I posted a message on their board, but I haven't heard anything yet. Does anyone have any experience with this?
OpenObex upstream is pretty much dead(-ish). Let's call it maintenance mode.
I have tried the fedora-list without an answer. Also, the OpenOBEX developers are silent on this. Is this because no one has a 2.0 adapter and 2.0 device?
Probably not, one of the upstream for OpenObex is Marcel Holtmann, and he certainly has more Bluetooth 2.0 devices than you or I.
Test the patch, tell us if it works, and mail the bluez-users list about it. There's also ACL and SCO MTUs to take in consideration, and I would guess the bug is more likely to be there (in the kernel, in the firmware of your dongle, or the firmware of your phone) than solely in OpenObex.
I will try messing with OpenOBEX and report back. If no one else ventures into this... it might be a while. I don't have a lot of time to give to this.
Cheers
-------- Original Message -------- Subject: Re:bluetooth 2.0 is extremely slow From: Mike Cronenworth mike@cchtml.com To: Bastien Nocera bnocera@redhat.com Date: 04/05/2008 12:50 AM
I punched myself into loading Windows XP (latest updates, latest drivers) and the same file (or any 1 meg file) transfers in *10 seconds*. A factor of four on speed improvement. There's nothing wrong with the firmware.
I saw someone fixed this by forcing larger MTUs. http://lists.freebsd.org/pipermail/...ary/000847.html http://lists.freebsd.org/pipermail/freebsd-bluetooth/2007-January/000847.html
Before modifying the OpenOBEX sources, I posted a message on their board, but I haven't heard anything yet. Does anyone have any experience with this?
OpenObex upstream is pretty much dead(-ish). Let's call it maintenance mode.
I have tried the fedora-list without an answer. Also, the OpenOBEX developers are silent on this. Is this because no one has a 2.0 adapter and 2.0 device?
Probably not, one of the upstream for OpenObex is Marcel Holtmann, and he certainly has more Bluetooth 2.0 devices than you or I.
Test the patch, tell us if it works, and mail the bluez-users list about it. There's also ACL and SCO MTUs to take in consideration, and I would guess the bug is more likely to be there (in the kernel, in the firmware of your dongle, or the firmware of your phone) than solely in OpenObex.
I will try messing with OpenOBEX and report back. If no one else ventures into this... it might be a while. I don't have a lot of time to give to this.
Cheers
OK,
I applied the attached patch. I'm putting this up for review, and any suggestions (should this be posted somewhere else, etc.). My transfer time went from 40 seconds to 10 seconds. It now matches Windows XP performance. Just add it to the RPM spec like the existing patches.
Regards, Michael
-------- Original Message -------- Subject: Re: bluetooth 2.0 is extremely slow From: Mike Cronenworth mike@cchtml.com To: mike@cchtml.com, Development discussions related to Fedora fedora-devel-list@redhat.com Cc: Bastien Nocera bnocera@redhat.com Date: 04/09/2008 09:53 PM
OK,
I applied the attached patch. I'm putting this up for review, and any suggestions (should this be posted somewhere else, etc.). My transfer time went from 40 seconds to 10 seconds. It now matches Windows XP performance. Just add it to the RPM spec like the existing patches.
Regards, Michael
After further testing I've created a proper patch. These are my results based on the attached patch. Each MTU was tested twice using "open_push" as the receiver program and using the "gnome-obex-server" program.
Bluetooth 2.0 - 1070k file transfer from phone to computer 1024 MTU - 40 seconds (default MTU) 8192 MTU - 20 seconds 16384 MTU - 10 seconds 32768 MTU - 11 seconds 65535 MTU - 12 seconds
Bluetooth 1.1 - 1070k file transfer from phone to computer 1024 MTU - 52 seconds (default MTU) 8192 MTU - 30 seconds 16384 MTU - 34 seconds
I revised the patch to not change the minimum MTU. It had no effect on speeds. 16k seems to be the sweet spot. This makes *huge* differences for both 1.1 and 2.0. It seems no one with OpenOBEX bothered to test transfer speeds... kind of unsettling. I will make a Bugzilla report and join the bluez list later today.
Regards, Mike
Mike Cronenworth wrote:
-------- Original Message -------- Subject: Re: bluetooth 2.0 is extremely slow From: Mike Cronenworth mike@cchtml.com To: mike@cchtml.com, Development discussions related to Fedora fedora-devel-list@redhat.com Cc: Bastien Nocera bnocera@redhat.com Date: 04/09/2008 09:53 PM
OK,
I applied the attached patch. I'm putting this up for review, and any suggestions (should this be posted somewhere else, etc.). My transfer time went from 40 seconds to 10 seconds. It now matches Windows XP performance. Just add it to the RPM spec like the existing patches.
Regards, Michael
After further testing I've created a proper patch. These are my results based on the attached patch. Each MTU was tested twice using "open_push" as the receiver program and using the "gnome-obex-server" program.
Bluetooth 2.0 - 1070k file transfer from phone to computer 1024 MTU - 40 seconds (default MTU) 8192 MTU - 20 seconds 16384 MTU - 10 seconds 32768 MTU - 11 seconds 65535 MTU - 12 seconds
Bluetooth 1.1 - 1070k file transfer from phone to computer 1024 MTU - 52 seconds (default MTU) 8192 MTU - 30 seconds 16384 MTU - 34 seconds
I revised the patch to not change the minimum MTU. It had no effect on speeds. 16k seems to be the sweet spot. This makes *huge* differences for both 1.1 and 2.0. It seems no one with OpenOBEX bothered to test transfer speeds... kind of unsettling. I will make a Bugzilla report and join the bluez list later today.
Regards, Mike
Does using OBEX_SetTransportMTU() help? http://www.zuckschwerdt.org/apidocs/r323.html
On Thu, 2008-04-10 at 19:39 +0200, Harald Hoyer wrote: <snip>
Does using OBEX_SetTransportMTU() help? http://www.zuckschwerdt.org/apidocs/r323.html
For what it's worth all the Obex UIs for GNOME in Fedora shouldn't have those speed problems, as obex-data-server sets the MTU itself as well, to values tested by Nokia for Maemo.