mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Marcel Holtmann <marcel@holtmann.org>
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:48:06 +0200	[thread overview]
Message-ID: <20051023094806.GB1975@elf.ucw.cz> (raw)
In-Reply-To: <1130059941.11428.81.camel@blade>

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 :-(.
> 
> 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.

No, sorry, that was over ppp over rfcomm. With MSI dongle, I get
25KB/sec with n6230. With bluetooth CF card, I only get 10KB/sec.

> > 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.

Rest is during transfer. I'd expect it to be slightly worse, but not
that 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?

This is against second linux box... Can't be 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.

On billionton card:

root@spitz:/bt# hcitool info <address of MSI card>
Requesting information ...
        BD Address:  <address of MSI card>
        Device Name: BlueZ (0)
        LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
        Manufacturer: Cambridge Silicon Radio (10)
        Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
                <3-slot packets> <5-slot packets> <encryption> <slot offset>
                <timing accuracy> <role switch> <hold mode> <sniff mode>
                <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
                <HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
                <power control> <transparent SCO>
root@spitz:/bt# hciconfig hci0 version
hci0:   Type: UART
        BD Address: <address of billionton> ACL MTU: 192:8 SCO MTU: 64:8
        HCI Ver: 1.1 (0x1) HCI Rev: 0x33c LMP Ver: 1.1 (0x1) LMP Subver: 0x33c
        Manufacturer: Cambridge Silicon Radio (10)
root@spitz:/bt#

On MSI side:

root@bug:~# hcitool info <address of billionton>
Requesting information ...
        BD Address:  <address of billionton>
        Device Name: billionton
        LMP Version: 1.1 (0x1) LMP Subversion: 0x33c
        Manufacturer: Cambridge Silicon Radio (10)
        Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
                <3-slot packets> <5-slot packets> <encryption> <slot offset>
                <timing accuracy> <role switch> <hold mode> <sniff mode>
                <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
                <HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
                <power control> <transparent SCO>
root@bug:~#

> You can also use "hcidump -X -V" to analyze the traffic.

Do you prefer hcidump on MSI or on billionton side? On MSI side it is
easy to get, but it is generating *big* logs.
								Pavel
-- 
Thanks, Sharp!

  reply	other threads:[~2005-10-23  9:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-22 17:31 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-26 18:18       ` Pavel Machek
2005-10-23  9:32 ` Marcel Holtmann
2005-10-23  9:48   ` Pavel Machek [this message]
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=20051023094806.GB1975@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=maxk@qualcomm.com \
    /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

all inboxes | Powered by JetHome®