[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] Axis baud rate



 > 
> > > Second, bluetooth should be able to send  packet with a len
> > > up to 4096, it is not true with Axis stack.
> >
> >on what layer ? this is configurable for each layer.
> I configured MTU of each layer from RFCOMM to HCI
> 

the usermode function rf_send has a temp buffer defined of 8192 (MAXSIZE)
which is used to create a non-fragmented memory chunk which is then sent to
rfcomm_send_data which then splits it up in the negotiated MTU for 
rfcomm which in turn splits it up in negotiated value of one l2cap mtu.

However, as stated in the readme you shouldn't use the current usermode stack
for performance critical issues, use the kernel mode stack instead,

/*
 * THE USERMODE STACK SHOULD ONLY BE USED FOR DEVELOPMENT AND
 * TESTING OF BASIC STACK FUNCTIONALITIES AND DOES NOT PROVIDE
 * THE FULL STACK FUNCTIONALITIES (blocking calls, multiple lines 
 * etc etc).
 */ 

> > > So when I try to send packet with a baud rate of 12 kb/s, there is
> > > congestion during send process and receive process. I try to
> > > change value of
> > > RFCOMM, L2CAP and HCI MTU but the max value available is 800.
> >
> >also configurable... see hci.h #define HCI_IN_SIZE 800
> I configured it but it seems that send process see always 800 
> (send_acl_packet hci. line 2840)

You can configure the IN hci max size but the OUT mtu size depends on your 
HW. 800 sounds like the buffer size in P3E module, to change this you need
either new HW or new firmware in the module.

> 
> > > For the send process, I identified one problem : one thread
> > > is created for each send.
> >
> >
> >where ? if you are talking about the usermode stack this creates
> >one thread used to read data from serial port and feed hci,
> >and one to write data to the pty (bt_receive_top).
> Yes I always work on usermode. It seems that there is one 
> thread for each 
> send...

> 
> >On the same connection, a unique structure is used
> > > to send data
> > > (bt_tx_buf in btcommon.h --> line 172), the problem is that
> > > this structure
> > > is not thread-safe : at high baud rate, at the same time, 2
> > > or more threads
> > > worked on this structure, so concurency problems occured and
> > > send process
> > > failed.
> >
> >some logs could be very useful.
> During debug of send process, I added two printf (trace1, trace2) in 
> send_acl_packet function (hci.c) :
> - At low baud, I can see : "trace1 ... trace 2 ... trace 1 
> ... trace 2"
> - At high baud, I can see : "trace 1... trace 1 ... trace 2 
> ... trace 2"
> This why, I think there is one thread by send

acl_send_packet just calls bt_write_lower_driver which in turn writes to the phys_fd
(serial port fd). This function call is done either in the pty_reveive_thread that gets the 
data from e.g ppp or directly from the main thread where the 'command line mode' is running.

To minize the risk of bugs, always use the latest code at www.sourceforge.org/projects/openbt.

The whole usermode stack is about to be remade using the code in /apps/bluetooth/experimental dir
and will then probably be more suitable for 'real' use.

/Mattias

> 
> franck
> ______________________________________________________________
> ___________
> Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com.
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com