From: Marcel Holtmann <marcel@holtmann.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: maxk@qualcomm.com, bluez-devel@lists.sf.net,
kernel list <linux-kernel@vger.kernel.org>
Subject: [Bluez-devel] Re: Billionton bluetooth CF card: performance is 10KB/sec
Date: Sun, 23 Oct 2005 11:32:21 +0200 [thread overview]
Message-ID: <1130059941.11428.81.camel@blade> (raw)
In-Reply-To: <20051022173152.GA2573@elf.ucw.cz>
Hi Pavel,
> Ping time is around 50msec, and that seems pretty much okay, but
> 10KB/sec seems like way too low.
>
> I am limited to 10KB/sec both on linux-to-linux bnetp transfers and it
> limits my transfer rates using edge and n6230, too :-(.
so you say that the Nokia 6230 has PAN Profile support and you don't
need any PPP crap to get Internet access? This would be the first phone
I have seen so far.
> Ping times during transfer:
>
> 64 bytes from 10.1.0.3: icmp_seq=149 ttl=64 time=62.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=150 ttl=64 time=64.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=151 ttl=64 time=85.9 ms
> 64 bytes from 10.1.0.3: icmp_seq=152 ttl=64 time=80.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=153 ttl=64 time=132.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=154 ttl=64 time=64.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=155 ttl=64 time=128.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=156 ttl=64 time=116.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=157 ttl=64 time=120.5 ms
> 64 bytes from 10.1.0.3: icmp_seq=158 ttl=64 time=240.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=159 ttl=64 time=111.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=160 ttl=64 time=382.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=161 ttl=64 time=912.6 ms
> 64 bytes from 10.1.0.3: icmp_seq=162 ttl=64 time=1612.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=163 ttl=64 time=4373.6 ms
> 64 bytes from 10.1.0.3: icmp_seq=164 ttl=64 time=5128.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=165 ttl=64 time=7191.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=166 ttl=64 time=9473.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=167 ttl=64 time=8469.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=168 ttl=64 time=10040.7 ms
> 64 bytes from 10.1.0.3: icmp_seq=169 ttl=64 time=9036.7 ms
> 64 bytes from 10.1.0.3: icmp_seq=170 ttl=64 time=10681.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=171 ttl=64 time=9677.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=172 ttl=64 time=8673.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=173 ttl=64 time=10685.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=174 ttl=64 time=9681.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=175 ttl=64 time=8677.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=176 ttl=64 time=11997.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=177 ttl=64 time=10993.4 ms
> 64 bytes from 10.1.0.3: icmp_seq=178 ttl=64 time=9989.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=179 ttl=64 time=13797.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=180 ttl=64 time=12793.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=181 ttl=64 time=11789.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=182 ttl=64 time=10784.9 ms
> 64 bytes from 10.1.0.3: icmp_seq=183 ttl=64 time=9781.1 ms
The initial pings look good, the rest is very bad.
> Netdev watchdog complains a lot:
>
> Oct 22 18:53:57 amd pand[2439]: Bluetooth PAN daemon version 2.19
> Oct 22 18:53:57 amd pand[2439]: Connecting to <won't tell you>
> Oct 22 18:53:58 amd pand[2439]: bnep0 connected
> Oct 22 18:54:37 amd kernel: usb 3-1: USB disconnect, address 2
> Oct 22 18:55:33 amd kernel: NETDEV WATCHDOG: bnep0: transmit timed out
> Oct 22 18:55:59 amd last message repeated 2 times
> Oct 22 18:56:51 amd last message repeated 5 times
> Oct 22 18:57:55 amd last message repeated 3 times
> Oct 22 18:59:03 amd last message repeated 7 times
The transmit timeouts shouldn't be there. The question is now which side
is at fault. The host or the phone?
Please do a "hcitool info <won't tell you>" as root so I can see which
what chip we are dealing. Also "hciconfig hci0 version" for your card
would help.
You can also use "hcidump -X -V" to analyze the traffic.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
WARNING: multiple messages have this Message-ID (diff)
From: Marcel Holtmann <marcel@holtmann.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: maxk@qualcomm.com, bluez-devel@lists.sourceforge.net,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Billionton bluetooth CF card: performance is 10KB/sec
Date: Sun, 23 Oct 2005 11:32:21 +0200 [thread overview]
Message-ID: <1130059941.11428.81.camel@blade> (raw)
In-Reply-To: <20051022173152.GA2573@elf.ucw.cz>
Hi Pavel,
> Ping time is around 50msec, and that seems pretty much okay, but
> 10KB/sec seems like way too low.
>
> I am limited to 10KB/sec both on linux-to-linux bnetp transfers and it
> limits my transfer rates using edge and n6230, too :-(.
so you say that the Nokia 6230 has PAN Profile support and you don't
need any PPP crap to get Internet access? This would be the first phone
I have seen so far.
> Ping times during transfer:
>
> 64 bytes from 10.1.0.3: icmp_seq=149 ttl=64 time=62.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=150 ttl=64 time=64.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=151 ttl=64 time=85.9 ms
> 64 bytes from 10.1.0.3: icmp_seq=152 ttl=64 time=80.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=153 ttl=64 time=132.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=154 ttl=64 time=64.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=155 ttl=64 time=128.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=156 ttl=64 time=116.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=157 ttl=64 time=120.5 ms
> 64 bytes from 10.1.0.3: icmp_seq=158 ttl=64 time=240.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=159 ttl=64 time=111.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=160 ttl=64 time=382.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=161 ttl=64 time=912.6 ms
> 64 bytes from 10.1.0.3: icmp_seq=162 ttl=64 time=1612.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=163 ttl=64 time=4373.6 ms
> 64 bytes from 10.1.0.3: icmp_seq=164 ttl=64 time=5128.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=165 ttl=64 time=7191.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=166 ttl=64 time=9473.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=167 ttl=64 time=8469.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=168 ttl=64 time=10040.7 ms
> 64 bytes from 10.1.0.3: icmp_seq=169 ttl=64 time=9036.7 ms
> 64 bytes from 10.1.0.3: icmp_seq=170 ttl=64 time=10681.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=171 ttl=64 time=9677.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=172 ttl=64 time=8673.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=173 ttl=64 time=10685.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=174 ttl=64 time=9681.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=175 ttl=64 time=8677.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=176 ttl=64 time=11997.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=177 ttl=64 time=10993.4 ms
> 64 bytes from 10.1.0.3: icmp_seq=178 ttl=64 time=9989.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=179 ttl=64 time=13797.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=180 ttl=64 time=12793.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=181 ttl=64 time=11789.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=182 ttl=64 time=10784.9 ms
> 64 bytes from 10.1.0.3: icmp_seq=183 ttl=64 time=9781.1 ms
The initial pings look good, the rest is very bad.
> Netdev watchdog complains a lot:
>
> Oct 22 18:53:57 amd pand[2439]: Bluetooth PAN daemon version 2.19
> Oct 22 18:53:57 amd pand[2439]: Connecting to <won't tell you>
> Oct 22 18:53:58 amd pand[2439]: bnep0 connected
> Oct 22 18:54:37 amd kernel: usb 3-1: USB disconnect, address 2
> Oct 22 18:55:33 amd kernel: NETDEV WATCHDOG: bnep0: transmit timed out
> Oct 22 18:55:59 amd last message repeated 2 times
> Oct 22 18:56:51 amd last message repeated 5 times
> Oct 22 18:57:55 amd last message repeated 3 times
> Oct 22 18:59:03 amd last message repeated 7 times
The transmit timeouts shouldn't be there. The question is now which side
is at fault. The host or the phone?
Please do a "hcitool info <won't tell you>" as root so I can see which
what chip we are dealing. Also "hciconfig hci0 version" for your card
would help.
You can also use "hcidump -X -V" to analyze the traffic.
Regards
Marcel
next prev parent reply other threads:[~2005-10-23 9:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-22 17:31 Billionton bluetooth CF card: performance is 10KB/sec Pavel Machek
2005-10-22 22:01 ` Ed Tomlinson
2005-10-23 8:35 ` Pavel Machek
2005-10-23 12:53 ` Ed Tomlinson
2005-10-23 12:53 ` Ed Tomlinson
2005-10-26 18:18 ` Pavel Machek
2005-10-23 9:32 ` Marcel Holtmann [this message]
2005-10-23 9:32 ` Marcel Holtmann
2005-10-23 9:48 ` Pavel Machek
2005-10-23 10:10 ` Marcel Holtmann
2005-10-23 10:18 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1130059941.11428.81.camel@blade \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sf.net \
--cc=bluez-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.