linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ed Tomlinson <tomlins@cam.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: marcel@holtmann.org, 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: Sat, 22 Oct 2005 18:01:48 -0400	[thread overview]
Message-ID: <200510221801.49314.tomlins@cam.org> (raw)
In-Reply-To: <20051022173152.GA2573@elf.ucw.cz>

On Saturday 22 October 2005 13:31, Pavel Machek wrote:
> Hi!
> 
> 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 :-(.
> 
> 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
> 
> 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
> 
> I use this to set up billionton:
> 
> setserial /dev/ttyBT baud_base 921600
> hciattach -s 921600 /dev/ttyBT bcsp
> 
> root@amd:~# tcpspray -n 1 -b 1000000 10.1.0.3
> 
> Transmitted 1000000 bytes in 163.256781 seconds (5.982 kbytes/s)
> 
> (okay, this was little slower, I was far from other side). Most tests
> look like this:
> 
> root@amd:~# tcpspray -n 1 -b 1000000 10.1.0.3
> 
> Transmitted 1000000 bytes in 103.183640 seconds (9.464 kbytes/s)

Pavel,

I see about the same with a bluetooth usb adapter.  Suspect that is about what
you should see with bluetooth - its not designed for speed.  It would be really 
nice to be wrong though...

Ed Tomlinson

       reply	other threads:[~2005-10-22 22:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20051022173152.GA2573@elf.ucw.cz>
2005-10-22 22:01 ` Ed Tomlinson [this message]
2005-10-23  8:35   ` Billionton bluetooth CF card: performance is 10KB/sec Pavel Machek
2005-10-23 12:53     ` Ed Tomlinson
2005-10-26 18:18       ` Pavel Machek
2005-10-23  9:32 ` [Bluez-devel] " Marcel Holtmann

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=200510221801.49314.tomlins@cam.org \
    --to=tomlins@cam.org \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).