<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> -------- Original Message -------- Subject: Re:bluetooth 2.0 is extremely slow From: Bastien Nocera <a class="moz-txt-link-rfc2396E" href="mailto:bnocera@redhat.com"><bnocera@redhat.com></a> To: <a class="moz-txt-link-abbreviated" href="mailto:mike@cchtml.com">mike@cchtml.com</a>, Development discussions related to Fedora <a class="moz-txt-link-rfc2396E" href="mailto:fedora-devel-list@redhat.com"><fedora-devel-list@redhat.com></a> Date: 04/01/2008 11:28 AM <blockquote cite="mid:1207067327.13201.242.camel@cookie.hadess.net" type="cite"> <pre wrap="">On Tue, 2008-04-01 at 11:11 -0500, Mike Cronenworth wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> That certainly doesn't rule out a bug in the dongle's firmware for example. </pre> </blockquote> 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. <blockquote cite="mid:1207067327.13201.242.camel@cookie.hadess.net" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">I saw someone fixed this by forcing larger MTUs. <a class="moz-txt-link-freetext" href="http://lists.freebsd.org/pipermail/...ary/000847.html">http://lists.freebsd.org/pipermail/...ary/000847.html</a> <a class="moz-txt-link-rfc2396E" href="http://lists.freebsd.org/pipermail/freebsd-bluetooth/2007-January/000847.html"><http://lists.freebsd.org/pipermail/freebsd-bluetooth/2007-January/000847.html></a> 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? </pre> </blockquote> <pre wrap=""> OpenObex upstream is pretty much dead(-ish). Let's call it maintenance mode. </pre> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> 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. <blockquote cite="mid:1207067327.13201.242.camel@cookie.hadess.net" type="cite"> <pre wrap=""> Cheers </pre> </blockquote> </body> </html>