[Bluez-devel] Headset via usb dongle devel problems.

[Bluez-devel] Headset via usb dongle devel problems.

[James Courtier-Dutton]

Hi,

I have discovered that the performance of the bluez stack is a problem 
when using the hci_usb.c driver.
I cannot get it to send SCO packets quicker than one urb per 40ms.
As the headset needs one urb per 3ms, this is quite a problem.
I would also assume that other applications like file transfer over 
bluetooth would be bad.
Would it be ok for the hci_usb.c driver to implement say 100 urbs per 
type. I.E. 100 output urbs for BULK, 100 output urbs for SCO etc.
The driver would then be sent a packet from the bluez stack and then get 
one of the 100 urbs, and send it immeadiately to the usb device 
(usb_submit_urb). But if all 100 urbs are used up, it would block, until 
an urb was freed (tx_complete callback).

Also, I need to know what the intended buffer management in the bluez 
driver is.
1) Application allocs some memory.
2) Application fills memory with data
3) Application calls bluez with pointer and length of memory.
4) What does bluez do now?
Does it: -
5) memcpy the data from user memory (maybe copyfromuser), add headers to 
it creating a packet, cutting it up into multiple packets if needed. 
(E.g. adding connection numbers etc.)
6) calls the low level device driver with pointer and length of packet.
7) low level device driver queues it for output. blocks here is the 
queue is full.
8) Returns control back to application.
9) low level device driver outputs the packet, and calls tx_complete 
callback.
10) tx_complete callback signals to higher layers in bluez that the tx 
is complete, and the higher layers release the memory.

For performance reasons, we should try to reduce the amount of 
alloc/free calls, and also reduce the amount of memcpy calls.
In my "Does it" section above, there is only one memcpy (copyfromuser), 
but it looks like the current bluez stack does many more memcpy's than that.

Can anyone help explain what does in fact happen at the moment.

Cheers
James



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Re: Headset via usb dongle devel problems.

[Jonathan Paisley]

On Fri, 11 Jul 2003 18:53:31 +0100, James Courtier-Dutton wrote:

> I have discovered that the performance of the bluez stack is a problem
> when using the hci_usb.c driver.
> I cannot get it to send SCO packets quicker than one urb per 40ms. As
> the headset needs one urb per 3ms, this is quite a problem. I would also
> assume that other applications like file transfer over bluetooth would
> be bad.

Have you identified what's actually causing this rate limit? It sounds
more like a scheduling issue to me than a number-of-memory-copies problem.

Would you consider sharing the code modifications you have made thus far?

I have been experimenting with two USB dongles with the aim of making the
PC act as a headset (I don't have one). I have been able to get reasonable
(although sometimes choppy audio) on the PC. That is, the sound is being
received by the PC. I haven't yet managed to test sending audio except for
/dev/zero. All this testing is with 2.4.20-mh10.

The two dongles I have are the Mitsumi WIF-0402c and the Sitecom CN-500,
which report as follows:

Sitecom CN-500:
$ sudo /sbin/hciconfig hci0 revision
hci0:   Type: USB 
        BD Address: 00:10:60:A2:E4:C2 ACL MTU: 192:8  SCO MTU: 64:8
        HCI 16.4
        Chip version: BlueCore02
        Max key size: 56 bit
        SCO mapping:  HCI

Mitsumi WIF-0402c:
$ sudo /sbin/hciconfig hci0 revision
hci0:   Type: USB 
        BD Address: 00:A0:96:1D:4A:AA ACL MTU: 128:8  SCO MTU: 64:8
        HCI 11.2
        Chip version: BlueCore01b
        SCO mapping:  HCI

The Mitsumi accepts the SCO connection and then gives up, whereas the
Sitecom is able to sustain the connection for as long as I have tested
(<2minutes). The Mitsumi is much older, so I'm not surprised there are
problems. However, both devices work okay in this manner under Windows.





-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Measuring throughput using l2test gives very high value.

[Aarti Kumar]

Hello,
I am trying to measure the throughtput between two
laptops with bluetooth connection.
The l2test gives a very high value : in theranhe of
34567 kB/sec 76578 kB/sec.
I am not able to understand what the problem is .
Also the Time taken to tranfer the data is printed as
0.00 sec.

Using following commands:
Server : ./l2test -r
Client : ./l2test -s baddr.

Thanks,
Aarti.

--- Jonathan Paisley <jp-www@dcs.gla.ac.uk> wrote:
> On Fri, 11 Jul 2003 18:53:31 +0100, James
> Courtier-Dutton wrote:
> 
> > I have discovered that the performance of the
> bluez stack is a problem
> > when using the hci_usb.c driver.
> > I cannot get it to send SCO packets quicker than
> one urb per 40ms. As
> > the headset needs one urb per 3ms, this is quite a
> problem. I would also
> > assume that other applications like file transfer
> over bluetooth would
> > be bad.
> 
> Have you identified what's actually causing this
> rate limit? It sounds
> more like a scheduling issue to me than a
> number-of-memory-copies problem.
> 
> Would you consider sharing the code modifications
> you have made thus far?
> 
> I have been experimenting with two USB dongles with
> the aim of making the
> PC act as a headset (I don't have one). I have been
> able to get reasonable
> (although sometimes choppy audio) on the PC. That
> is, the sound is being
> received by the PC. I haven't yet managed to test
> sending audio except for
> /dev/zero. All this testing is with 2.4.20-mh10.
> 
> The two dongles I have are the Mitsumi WIF-0402c and
> the Sitecom CN-500,
> which report as follows:
> 
> Sitecom CN-500:
> $ sudo /sbin/hciconfig hci0 revision
> hci0:   Type: USB 
>         BD Address: 00:10:60:A2:E4:C2 ACL MTU: 192:8
>  SCO MTU: 64:8
>         HCI 16.4
>         Chip version: BlueCore02
>         Max key size: 56 bit
>         SCO mapping:  HCI
> 
> Mitsumi WIF-0402c:
> $ sudo /sbin/hciconfig hci0 revision
> hci0:   Type: USB 
>         BD Address: 00:A0:96:1D:4A:AA ACL MTU: 128:8
>  SCO MTU: 64:8
>         HCI 11.2
>         Chip version: BlueCore01b
>         SCO mapping:  HCI
> 
> The Mitsumi accepts the SCO connection and then
> gives up, whereas the
> Sitecom is able to sustain the connection for as
> long as I have tested
> (<2minutes). The Mitsumi is much older, so I'm not
> surprised there are
> problems. However, both devices work okay in this
> manner under Windows.
> 
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems
> on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell
> virtual machines at the
> same time. Free trial click here:
> http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/bluez-devel


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Headset via usb dongle devel problems.

[Max Krasnyansky]

At 10:53 AM 7/11/2003, James Courtier-Dutton wrote:
>Hi,
>
>I have discovered that the performance of the bluez stack is a problem when using the hci_usb.c driver.
>I cannot get it to send SCO packets quicker than one urb per 40ms.
>As the headset needs one urb per 3ms, this is quite a problem.
Interesting. We shouldn't have any limitations in this area.

>I would also assume that other applications like file transfer over bluetooth would be bad.
They aren't :). L2CAP, RFCOMM, BNEP transfers using USB devices easily achieve max Bluetooth
throughput. And if you do it over HCIEmu you get numbers like 5Mbytes/sec. So HCI core and
ACL scheduler is pretty darn fast :)

>Would it be ok for the hci_usb.c driver to implement say 100 urbs per type. I.E. 100 output urbs for BULK, 100 output urbs for SCO etc.
This is not needed. I did quite a bit of testing with URB queuing, submitting more than 4 tx/rx 
URBs does not seem to improve performance. In fact you can easily saturate Bluetooth link even if 
use submit one URB at a time and wait for completion. I'm talking about bulk URBs here, like you 
showed in prev emails emails isoc is different.

>Also, I need to know what the intended buffer management in the bluez driver is.
>1) Application allocs some memory.
>2) Application fills memory with data
>3) Application calls bluez with pointer and length of memory.
>4) What does bluez do now?
>Does it: -
>5) memcpy the data from user memory (maybe copyfromuser), add headers to it creating a packet, cutting it up into multiple packets if needed. (E.g. adding connection numbers etc.)
>6) calls the low level device driver with pointer and length of packet.
>7) low level device driver queues it for output. blocks here is the queue is full.
>8) Returns control back to application.
>9) low level device driver outputs the packet, and calls tx_complete callback.
>10) tx_complete callback signals to higher layers in bluez that the tx is complete, and the higher layers release the memory.
Very very close :).

Here is what happens in case when for example L2CAP application calls send() on L2CAP socket:

1) L2CAP allocates new SKB, does copy_from_user() and passes SKB to the HCI core.
2) HCI core adds HCI headers (SKB has room reserved for that), puts SKB into TX queue
of the appropriate ACL connection and schedules TX task.
3) TX task wakes up, decides which packets to send now (based on various counters) 
and hands those packets over to the HCI driver (let's say HCI USB driver).
4) HCI USB driver allocates URB (URB is initialized to use data buffer of the SKB) and
submits URB.
5) Once transfer is complete USB core calls hci_usb_tx_complete() call back which destroys 
SKB.

So, the answer is - yes we do only one copy.

Max



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel